Раз в две недели мы проводим общий созвон студии, где общаемся на разные темы: про книги, фильмы, мемы, бёрдвотчинги другие классные штуки.
На последней встрече я рассказал о принципах студии, которые сложились за пять лет её существования. Некоторые из них появились совсем недавно, а некоторые — с первого дня работы.
Делюсь публично, потому что хорошего должно быть больше. Будет интересно клиентам студии и всем, кто руководит удалёнными командами.
В январе к нам в студию обратилась Гюнель Тагирова, основательницы бренда одежды «Кика». Когда-то мы снимали офис напротив друг друга и сделали футболки с фразами про Сибирь.
Гюнель пришла с таким запросом: «Хочу сделать сайт для мерча. На какой платформе лучше делать?» Как обычно, я начал с вопроса: «А зачем тебе вообще сайт?» Из ответов стало ясно, что, сайт скорее всего не нжуен. Но что именно нужно, тоже было неясно. Чтобы найти решение, я предложил Гюнель консультацию.
Первым делом — разбираюсь, почему нужен именно сайт, а не что-то другое
Подготовка
Прежде чем предлагать какое-то решение, я разбираюсь в контексте: смотрю на то, какой это бизнес, в какйо нише, кто его клиенты, как они узнают о бинесе, почему покупают, какие задачи и вызовы сейчас стоят перед клиентом. Чем больше информации я соберу, тем лучше.
Я знал, чем занимается Гюнель, и тем не менее, перед консультацией я выслал ей список уточняющих вопросов и попросил прислать материалы о своём бизнесе: фотографии мерча, тексты холодных писем и пр. С тех пор как я общался с ней прошло несколько месяцев, и что-то могло измениться.
Когда дело касается решения сложных и нетривиальных задач, нельзя полагаться на свой опыт и знания из прошлого, потому что они могли устареть. Я стремлюсь и рекомендую всем принимать решение на основе самых свежих данных и фактов.
Даже если вы составили понимание задачи всего две недели назад, но всё это время не общались с клиентом, а потом он вернулся и предложил начать работу, не спешите. Две недели — огромный отрезок времени для бизнеса, особенно для российского, где год за три. Как минимум сначала следует заново пройтись по пониманию задачи и убедиться, что оно не изменилось. А, возможно, вам придётся составить новый документ.
Проблемы бренда
Главной проблемой была визуальная подача: в одном кейсе рядом стояли совершенно разные по настроению фотографии, которые противоречили друг другу. Например, сначала серьёзный парень.
А после него фото с улыбающейся командой кофейни. Конечно, больше отклика вызывает второе фото, возникает мысль: «Если я закажу мерч у Гюнель, то моя команда так же будет радоваться этому, и мы будем более сплочёнными, чем раньше». Мерч — это продукт про эмоции, философию и людей, а не про одежду.
Некоторые фото были настолько тёмными и неконтрастными, что было невозможно разобрать детали.
А некоторые подавали продукцию неряшливо: в кадре было много лишних деталей, что мешало увидеть главное — качество ткани и пошива.
Цель консультации
До консультации Гюнель сформулировала свой запрос так: «Я делаю мерч из премиальных тканей. Хочу, чтобы у меня было портфолио, которое донесёт до клиентов ценность сделать одежду, которая прослужит долго. Для этого хочу сделать сайт про свои услуги по пошиву мерча».
На консультации она хотела понять, нужно ли ей делать сайт, и если нет, то какие ещё решения существуют, в чём их преимущества и недостатки. Кроме этого, ей было важно получить обратную связь по визуальной подаче услуги пошива мерча.
Что было на консультации
На основе материалов и ответов Гюнель я составил подробный документ с разбором ошибок и рекомендациями. На консультации я открыл этот документ и прошёлся по нему, прокомментировал каждый пункт, объяснил главные проблемы бренда и предложил решения.
Встреча состояла из нескольких смысловых блоков:
Тексты и позиционирование. Я дал советы, как переписать тексты, чтобы они перестали звучать неуверенно. В премиальном сегменте нельзя писать «предлагаем вам заказать мерч» или «внешний вид сотрудников — очень важный аспект любого бизнеса».
Нужно прямо сказать и показать заказчику, в чём польза качественной одежды для сотрудников.
Визуальное оформление: фотографии и подача материалов. В портфолио «Кики» были и удачные фото, и мы решили, что они станут референсами для будущих фотосъёмок. Я составил подробный список рекомендаций, как надо и не надо снимать моделей, объяснил разницу между контентом для соцсетей и портфолио. Например, в сторис можно выкладывать процесс и пробные модели, снятые на айфон, а в портфолио стоит класть только фото мерча на людях, сделанные в студии при хорошем освещении.
Бизнес-процесс и его отражение в договоре. Дал примеры юридических формулировок, которые помогут сделать фотосессии частью проекта и позволят использовать снимки мерча в рекламных целях. В студийном договоре есть такой пункт, и он сильно похож на то, что нужно было Гюнель.
Гюнель задавала дополнительные вопросы, а я отвечал и подробно разбирал каждый нюанс. К концу встречи мы составили список задач, которые ей предстояло выполнить, чтобы решить текущие проблемы в своём деле и донести ценность своего продукта до потенциальных клиентов.
Результат
По итогу часовой беседы Гюнель получила:
Подробный разбор ошибок, которые мешали её клиентам понять ценность мерча
Рекомендации по стилю фотографий и презентации своих работ
Чек-лист с решениями, которые позволят выпускать новые кейсы регулярно
Варианты, как оформить портфолио, на четыре разных бюджета
Документ с разбором и рекомендациями был готов к концу встречи, и я сразу выслал его Гюнель.
В итоге, Гюнель решила сделать презентацию, и заказала её в нашей студии. В ней мы решили все проблемы, которые выявили на консультации и создали базу для простой и очень живой айдентики, которая отсылает к пошиву одежды. Получилась невероятно красивая презентация, которая стоила раз в пять-шесть дешевле, чем сайт.
Часто в проект проскакивают задачи, которые вы с клиентом обсуждали на старте, но решили пока не делать. Так происходит потому клиент всегда хочет максимум за минимум денег, а исполнитель не хочет обидеть клиента отказом и прослыть жмотом. Желание клиента вполне понятно и оправдано, однако, и жмотства в этом никакого нет.
Отложить что-то на старте проекта значит освободить время и место в голове для более важных задач, без решения которых проект не запустится. Чем больше задач вы пытаетесь упихнуть в единицу времени, тем дальше вы от цели. И, наоборот, чем меньше объём работы, тем выше вероятность создать работающее решение и запуститься в срок. На практике все это знают, но когда находишься в проекте, очень легко закопаться и согласиться на дополнительную неоплачиваемую работу.
Не сделать лишнего помогает такой приём — добавить в понимание задачи пункт «Что мы не делаем». Не просто обсудить с клиентом, мол, да-да, вот эту интеграцию с ЦРМ пока делать не будем, а прям записать в документ в отдельный пункт с деталями. Многим это кажется странным, мол, я-то точно не забуду. Забудете.
Люди всё забывают и очень быстро.
Через две-три недели ни вы, ни клиент не вспомните, о чём договорились и что там было с той самой интеграцией. Вроде бы обсуждали, да, но что именно решили, уже не помним. Хм, ну давайте сделаем. С этого момента всё летит в пизду: сроки сдвигаются, приходится перекидывать людей с одних задач на другие, работать по ночам. Всего этого можно избежать, добавив в понимание задачи пару строк.
Вот план действий на случай, если клиент пришёл с задачей, которую вы отложили:
Не бросать текущие задачи и не бежать сломя голову чего-то там делать, рисовать и писать.
Пойти посмотреть, что вы писали в понимании задачи и о чём договорились.
Вернуться к клиенту с ответом: «Да, Иван Иваныч, понимаем, но мы с вами решили пока это не делать. Можем взять в следующий спринт, цикл, вынести в отдельный проект, когда закончим текущий».
Конечно, всё это будет работать, только если вы прикрепляете и подписываете понимание задачи к договору в качестве приложения. Без договора клиент может нагнуть вас как хочет: требовать любую работу, менять условия и в принципе вам не платить.
Автор присылает на провереку пост, где есть перечень из четырёх пунктов. Три пункта — хорошие, с примерами и фактурой, а четвёртый — дохлый, на одну строчку. Рядом с остальными пунктами перечня он выглядит неуверенно, неполноценно.
Я пишу комментарий, что так не пойдёт: все пункты перечня должны быть равноценны между собой. Автор берёт и доливает в слабый пункт «воды». Становится ещё хуже: теперь у нас в перечне три полезных пункта и один — с притянутыми за уши фактами и обтекаемыми формулировками.
Снова пишу комментарий. Автор начинает двигать слова, но это не помогает. Так продолжается какое-то время, пока я не задаю вопрос: «А какую проблему ты пытаешься этим решить?» Оказалось, автор был уверен, что должен перебрать как можно больше решений. Это частое заблуждение.
Работа исполнителя не в том, чтобы сделать больше: написать больше текста или подвигать пиксели в макете. Иногда работа в том, чтобы не делать ничего. Иногда нужно перестать искать новое решение, и пересмотреть проблему, изменить её, переформулировать.
Вот несколько примеров:
В списке появился куцый пункт, и вы не знаете, что туда дописать — уберите этот пункт. Это лучше, чем оставить прежний список с дохлым пунктом.
В макете есть экран с плохой компоновкой, запуск уже через неделю, и вы понимаете, что со всеми согласованиями разработчики не успеют выкатить эти изменения в срок. Передоговоритесь с клиентом о том, чтобы запустить сайт без этого экрана. Это лучше, чем отложить пуск.
Вы сели писать письмо другу, но слова не складываются в текст. Значит, сегодня явно не тот день, чтобы страдать над белым листом. Отложите письмо, займись другими делами. Это лучше, чем отправлять вымученное письмо.
Если не можете найти решение, возможно, вы решаете не ту проблему. Смените фокус и убедитесь, что дело именно в решении, а не в чём-то ещё. Возможно, лучший вариант — это отступить от намеченного плана и не делать ничего и дать решению созреть.
Начинаю серию бесплатных постов про ошибки на старте проекта. Планирую около 5−6 постов, но может и больше. Тут уж как пойдёт. Первый — про брифы и техзадания.
Кратко
Бриф — это грабли, которые потом бьют по лбу, а иногда и по яйцам, если они у вас есть, в самый неожиданный момент. Брифы, заполненные без вас — шлак. Не тратьте на брифы ни время клиента, ни своё. Составляйте понимание задачи сами на созвоне или личной встрече.
Подробно
Заставлять клиента заполнять брифы до встречи — дурной тон. Это перекладывание ответственности и своей работы на заказчика. Со стороны выглядит дико: вы там напишите, чего вам надо, а я почитаю и скажу, что я про это думаю. То есть исполнитель скинул свою работу на заказчика и курит бамбук.
Требуя заполнить бриф, исполнитель лишается главного — возможности построить долгосрочные отношения с будущим клиентом и понять, его ли это проект. Бриф повышает риск ввязаться в проект с дурным контекстом, потому что в тексте невозможно заметить те самые «подводные камни». Нужна встреча, живое общение, контакт.
Другая проблема в том, что в 99% случаев брифы не помогают сделать проект хорошо. Клиенты заполняют их наотъебись, упуская важные детали. И они не со зла: у них нет времени на ещё одну анкету, и они в самом деле не знают, что важно для проекта, а что нет. Потому и пришли к исполнителю, чтобы тот помог разобраться, взял часть ответственности и помог.
То же самое касается техзаданий, который заказчик составил с кем-то до вас. Большая часть этих документов бессмысленная хуйня, где школярским языком описывается, сколько экранов должно быть на сайте, с какой стороны должна стоять кнопка. Всё это не имеет никакого отношения к решению задачи и проекту.
Некоторые клиенты могут использовать техзадания в качестве аргумента в переговорах о стоимости. Мол, вот это нам обещали сделать за пять рублей в студии «Пурпурный карась», давайте и вы так же. Я в такие моменты отвечаю: «Так, а зачем покупать у меня? Идите туда и делайте за пять рублей там. У меня это стоит вот столько».
Чужие договорённости с кем-либо не должны влиять на ваши договорённости с клиентом. Поэтому ТЗ идут нахуй. Их можно читать, но по моему опыту, к ним никто никогда не возвращается, кроме госзаказчиков. Там ТЗ — это священный документ, но этот случай мы не рассматриваем, потому что я про это ничего не знаю.
Что это такое?
Серия бесплатных постов про ошибки на старте проекта. Планирую около 5−6 постов, но может и больше. Тут уж как пойдёт. Вот оглавление:
Ещё прошлой осенью я начал понимать, что слишком много времени трачу на встречи и обсуждения задач. Минимум три-четыре часа в неделю уходило на различного рода планёрки и встречи, на которых мы искали решение отдельной проблемы.
Как выглядит обычная онлайн-планёрка: один человек проговаривает статусы задач, которые уже и так записаны в таск-менеджере, а остальные скучают, тупят в телефоны и думают, как бы поскорее свалить. Тоска смертная!
С января этого года в качестве эксперимента я отменил все планёрки в студии. И ничего страшного не случилось. Работа не встала, дедлайны не сорвались. Наоборот, у людей появилось больше времени на вдумчивую, спокойную работу.
Оказалось, что многие вещи можно решить письменно. А ещё почти всегда лучше сначала написать, а потом обсуждать. Это невероятно сокращает количество и длительность встреч, а ещё повышает качество идей и их проработку.
Формулировка мыслей в письменном виде исключает возможность переложить задачу и её решение кого-то другого, скинуть её с себя. Не то, чтобы у нас это когда-то было нормой, но теперь это в принципе невозможно.
«А как же сплочённость команды, тимбилдинг и вот это всё?» — спросите вы. Я всегда считал, что это надуманная хуйня. Такие вещи не формируются на планёрках. От того, что мы мысленно возьмёмся за руки и помолимся в Зуме, мы не станем командой. Скорее, наоборот, такие вещи вызывают рвотный рефлекс.
Вместо планёрок мы стали проводить неформальные беседы, где болтаем о чём угодно. Например, на первой встрече говорили про велосипеды, теннис и о том, как скоро нас заменят роботы. На второй — про сон, важность отдыха, ошибки при откликах на вакансии и даже немного про политику.
Пока решили, что продолжим делать такие встречи раз в две недели. Это не слишком часто, чтобы надоесть, и не слишком редко, чтобы чувствовать себя оторванным от команды. Главное условие: хочешь приходит, хочешь нет. Никакой обязаловки.
Если вы менеджер или не дай бог основатель, вас не должно быть много на такой встрече. Дайте людям высказаться первыми, комментируйте по делу, но не выпячивайтесь, иначе приятные посиделки превратятся в ваш стендап.
Иногда я получаю отклики от кандидатов, которых скорее всего бы взял на работу или как минимум позвал на собеседование. Однако я не не зову их работать со мной из-за одной идиотской детали: неуместной дерзости…
Понимание, что встреча не нужна, высвобождает огромное количество времени. На старте я любил встречи, а теперь стараюсь сокращать их количество и как можно больше вопросов решать асинхронно.
Любая встреча должна иметь три блока: — повестку — цель — список тем и вопросов к обсуждению
Если чего-то из этого нет или оно сформулировано невнятно, встреча под вопросом. Пользуйтесь этим знанием и не бойтесь отменять встречи.
Проверить, не напрасной ли была встреча, можно так же. По итогам любой встречи должен появиться документ с двумя списками: — список договорённостей — список задач со сроками и ответственными
Если ни одного списка нет, встречу можно было не проводить.
Главный секрет успевать больше заключается в том, чтобы сократить количество встреч. Половина встреч, которые проводят люди, нахуй не нужны. Огромное количество вопросов можно решать асинхронно.
Лучший момент на встрече, когда клиент говорит, что ему нихуя непонятно. Если вы слышите такое, это хороший знак, и вот почему:
Клиент с вами честен и прям. Он вам доверяет и знает, что вы спокойно воспримете даже такой ответ. Клиент, который вам не доверяет, никогда так не скажет, да ещё и матом.
Клиент только что сообщил «У нас проблема». Вам осталось лишь её определить и устранить.
Клиент только что сообщил: «Вы не попали в цель». Это может означать, что решение слишком сложное или что клиент ожидал увидеть что-то другое.
В такие моменты не нужно ничего делать и говорить. Тем более не стоит спорить и возражать, что «у вас всё понятно». Не выставляйте заказчика идиотом: если он не понял, значит не понял, надо разобраться.
Сделайте паузу. Как правило она длится не долго, и заказчик сам начинает изливать душу. В этот момент заткнитесь и слушайте. Скорее всего узнаете что-то важное о продукте и ожиданиях от результата.
Так на одной из недавних встреч мы узнали, что нет смысла показывать клиенту текстовые черновики: без визуальной структуры он ничего не понимает. Ему важно увидеть черновой эскиз, чтобы представить, где будет заголовок, где картинка, где кнопка. Ещё выяснилось, что сейчас горят не те страницы, что мы принесли, а другие, которые изначально отложили.
Не пугайтесь, если клиенту ничего непонятно. Это идеальный момент, чтобы разобраться в проекте и выяснить, чего от вас хотят.
Бывает, что заказчик ранее не работал с редакторами. Из-за неопытности он не знает, как давать обратную связь по черновику. Вместо замечаний заказчик предлагает свои варианты отдельных фраз, двигает слова, переписывает текст. В этот момент у редактора возникает соблазн начать учить заказчика. Я тоже попадал в такие ситуации и вёл себя как мудак…
