Анна Доронина. Не сдаваться! — Кто студент

Анна Доронина Не сдаваться!

Дизайнер о дипломном проекте, согласовании замечаний и ошибках на третьей ступени.

Расскажи для начала, что ты делала на третьей ступени.

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

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

Сервис мы делали вместе с Николаем Товеровским. У него была идея сделать сервис, который поможет в онлайне проводить встречу по этому алгоритму. Обычно команды на третьей ступени работают с арт-директором и шефом, а у нас был ещё и заказчик.

Николай Товеровский о согласовании замечаний в книге «Управление проектами, людьми и собой»

Как вы собрались?

Проект делали ребята с седьмого потока, а я пришла с шестого: уходила в академ. Когда обратилась с просьбой восстановить меня на седьмом потоке, осталось только место руководителя. Мы объединились в группу и стали думать над идеей проекта. Пока думали, появилась Ксюша — руководитель с седьмого потока, которая не попала на бесплатное место и не нашла денег на третью ступень. Но в итоге ей удалось это как-то решить. Она нам написала, всех уговорила, мы начали делать проект вчетвером: два дизайнера, редактор и руководитель.

Как проходила первая встреча с заказчиком?

Я стала руководителем к середине проекта, так что вопрос не ко мне. Общение, насколько я знаю, проходило по скайпу: разговаривали о том, как заказчик видит проект, Ксюша задавала вопросы Горбунова и немного своих. После написали понимание задачи — краеугольный камень диплома.

Николай не зря ведёт курс «Управление проектами, людьми и собой», он очень организован. Когда у него было время, руководитель с ним созванивался и рассказывал о том, что сделано, а Николай говорил, что нравится и не нравится. Встречи были расписаны, поначалу всё было организованно.

Первый вариант. Всё непонятно и сложно. Колонки снизу нечитаемы. Пользоваться неудобно

Вариант не понравился заказчику: лишние колонки, текст замечаний слишком узкий

Окончательный вариант. Утвердили у всех. На практике оказался не очень: слишком яркие кнопки, портят читабельность текста

Спрошу тебя о больном для всех моменте — о понимании задачи. Как у вас получилось его сформулировать, какие ошибки допустили?

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

Так получилось, потому что мы завязли с дизайном. Решили, что сначала его согласуем, а потом пойдём дальше, поэтому в итоге сильно отстали от графика. Когда я стала руководителем, увидела, что в зачётке нет ни одного зачёта, поэтому вернулись опять к пониманию задачи.

Про понимание есть полезная лекция у Ильи Бирмана: он рассказывает, как пишут понимание задачи в бюро. Суть в том, что надо для начала определиться с целью бизнеса. У бизнеса всегда есть задача: привлечь людей, продать что-то, повысить конверсию. И бизнес-задачу решают с помощью дизайна: например, собрать галерею фотографий на первой странице сайта, сделать рекламный баннер. Бирман всегда говорит, что решать задачу бизнеса нужно с помощью задач дизайна. Его лекция нам очень помогла.

Кто у вас был шефом и арт-директором?

Шефом был Артём Горбунов, арт-директором — Илья Бирман, а Николай Товеровский был отдельно, выступал как клиент.

Как взаимодействовали с шефом и арт-директором?

На самом деле, с шефом мы особо не взаимодействовали: на электронную почту присылали вопросы, а он отвечал, когда ему было удобно. Я знаю, что некоторые шефы советуют, тренируют, но не Горбунов. Если к нему обращаются — помогает, не обращаются — значит не надо.

А с Бирманом мы общались и получали комментарии в Телеграмме. Чаще всего отправляли готовые файлы: макет или прототип. В первую итерацию отправляли без вопросов, во второй раз рассказывали об изменениях и получали по ним комментарии. Бирман отвечает в Телеграме по системе «вопрос-ответ» — быстренько, и нужно подстраиваться под удобное для него время.

Комментируют в бюро жёстко: на второй ступени ещё помягче, а на третьей могут написать, что проект — говно. Но всё зависит от того, кто арт-директор: кто-то матом пишет, кто-то помягче. Нозик вот мягко отвечает. В комментариях говорят, что не нравится, советуют, как исправить: «Напиши так, выдели курсивом, сделай здесь плашку». Дают конкретные советы, по крайней мере Бирман.

В итоге убрали цвета, изменили иконки, вписали в сайт

Как в команде воспринимали такие комментарии?

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

Самый обидный для тебя комментарий?

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

Сначала проект назывался «Минутки», потом изменили на «Замечания». «Минутки» — потому что по-английски minutes of meetings — записи со встречи, и Николай хотел такое название. Мы отнеслись спокойно, а Артём Горбунов как создатель этого алгоритма был против. Минутки в русском языке никак не связаны с записями, замечаниями или встречей. Это заимствование нелогично и сбивает с толку.

Как работали с Николаем как с заказчиком?

Мы строили взаимодействие неправильно, в этом наша ошибка. Показывали работу Илье и Николаю параллельно: отправляли сразу и тому, и другому. Естественно, у Ильи были свои замечания, у Николая — свои. Когда получали две стопки замечаний, не знали, что именно исправлять. Приносим Илье исправленное, а там не только то, что мы учли по его замечаниям, но ещё и правки по замечаниям Николая. С Николаем было тоже самое. Нужно было показывать утверждённый у арт-директора макет Николаю и принимать его замечания.

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

Какие советы ты могла бы дать по взаимодействию с арт-директором и клиентом, если это клиентский проект?

С арт-директором важно наладить контакт и найти удобное для него время. Мы пытались договориться с арт-директором о конкретном дне, но ему было неудобно. Под арт-директора нужно подстраиваться. Например, Артём Горбунов пишет в общем чате, когда у него есть свободное время и когда он готов обсуждать проект. Николай выбирает удобное время для скайп-конференции. Бирману так неудобно: ему лучше писать в вечернее время, тогда он готов посмотреть идеи и наброски. Тогда должна подключаться вся команда, чтобы оперативно реагировать на замечания. Бирман отвечает быстро, за это время многое можно переделать.


Делали главную инонку. Не получалось. Илья предложил вариант









Педантично согласовывали карандаш

Ты пришла в команду руководителем на шестой неделе. Как ты строила взаимодействие с командой, с какими проблемами столкнулась?

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

Важно узнать планы каждого участника команды и время, когда они смогут работать. У нашего дизайнера был аврал на работе и почти неделю он не мог рисовать. Повезло, что у нас два дизайнера. Такие моменты важно заранее обсудить в команде, всегда кто-то не сможет: отпуск, конференции, проблемы. Нужно планировать сразу так, чтобы другой участник команды вовремя подстраховал.

Ещё у нас один дизайнер рисовал в Фотошопе, а второй — в Скетче. И когда они передавали макеты, при конвертации возникали ошибки: слои растрировались, пиксели скакали. На этом этапе нас спас онлайн-редактор «Фигма». Он бесплатный и по функционалу похож на Скетч. Ещё он простой: любой участник команды без дизайнера мог заменить заголовок, вписать текст. Работать стало намного легче, когда внедрили Фигму.

Больной вопрос к тебе как к руководителю — как не делать впритык?

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

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

Возможно, такое решение может спасти ребят, которые не успеют сделать проект. Проект может быть не готов, а в промостранице почти нет программирования, она статичная. Мы сделали и утвердили страницу за неделю. Это не так затратно по ресурсам, но очень хорошо подстраховывает.

Обсуждаем с арт-диром что и как флексить. Потом утвердили у Николая. Ибо нельзя флексить без разрешения клиента

Расскажи про этап перед защитой и про саму защиту.

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

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

Общий вид в редакторе Фигма. Строки — версии дизайна

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

Презентация на защите правда такая стрессовая?

На защите я была дистанционно, но судя по ребятам — это очень стрессово. Особенно когда задают вопросы: теряешься и не знаешь, что ответить. Уже после защиты какое-то проходит время, и ты понимаешь, что надо было ответить по-другому.

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

Как ты думаешь, что делает проект жизнеспособным на третьей ступени и работоспособным после?

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

В этом плане помогает хорошо проработанное понимание задачи. Илья Синельников давал советы в чате третьей ступени и рассказывал, на какие вопросы нужно ответить во время проработки понимания задачи:

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

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

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

То, что показали на дипломе как готовый продукт. Ключевые моменты: интерфейс сервиса, ссылка на канал ФФФ. воркс в Телеграм, ссылка на книгу с теорией

Что посоветуешь студентам, которые недавно перешли на третью ступень?

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

Наладить общение с арт-директором, найти удобное для него время. Если есть возможность, дать поговорить руководителю, арт-директору и дизайнеру одновременно в скайпе — это вообще круто. Или, например, договориться прийти в кафе, как было с Артёмом Горбуновым.

Очень важно заранее найти программиста нужной специализации. Мы нашли не того: он сделал только часть работы и в середине проекта команда осталась без программиста. Другие ребята в последний момент писали в общем чате о том, что срочно ищут верстальщика. Неделя до допуска, а в чате висит сообщение «Скорее нужен верстальщик!» Лучше сразу найти программиста для подстраховки.

И главное — не сдаваться! У нас были случаи, что кто-то уходил, и команда страдала. Нужно стараться не бросать свою команду, ведь у каждого своя польза. Наладить общение в команде: руководитель должен доносить до дизайнера то, о чём просил арт-директор. Мы иногда приносили на проверку не то, о чём нас просил арт-директор, в итоге переделывали и теряли время.
Конспект — вторая версия сервиса