Комментарии 14
комментариях вы можете написать: «Дизайнеры отнимают хлеб у тестировщиков», «А как же повышенная нагрузка на дизайнера?» или «Ещё один говорит, что делать разработчику»
А вот и нет, я спрошу другое....
А когда озон перестанет каждый раз при оплате выставлять галку "сохранить данные карты"? Или я никак не пойму что это ради моего удобства *сарказм*?
Мне бы очень хотелось, чтобы вы добавили ещё проверку "нет интернета".
Был неприятно удивлён когда пришёл в пункт выдачи и оказалось, что без интернета я не могу увидеть уже просмотренные заказы. Не понимаю почему они не могут находиться в кеше хотя бы на 1-2 дня.
А в чём проблема картинки без дизайн-ревью?!!
Есть ощущение, что будут расти сроки Time 2 Market или Cycle time (в зависимости от того, что меряете) и такое решение может сделать все-таки "узкое горлышко" в процессе, особенно, если по результатам review потребуется делать доработки. Не анализировали этот момент?
Привет! Спасибо за вопрос.
Можно сказать, что убрав QA из флоу разработки деливери ускорится, зато, очевидно, качество разработки упадет. С дизайн-ревью то же самое: да, оно может влиять на Time-to-Market. Можно пойти дальше и отказаться от любых проверок, сразу после написания кода лить на продакшен — флоу станет быстрым, но какой ценой. Это скорее стратегический вопрос: как я и писала, дизайн-ревью можно вообще не проводить, это на усмотрение команды и как в ней ищут баланс скорость-качество.
Сейчас у нас бывает 2 ситуации:
Дизайнеры проводят дизайн-ревью параллельно с тестировщиком и заканчивают до завершения работы тестировщика над этой задачей, потому как приоритет на тестирование разработки у дизайнеров самый высокий. И всё-таки проверка дизайна и удобства занимает меньше времени, чем у тестировщика, так как логика и различные корнер-кейсы по большей части на стороне тестирования.
Нет времени на исправления и важно поправить только замечания с высоким и средним приоритетами (те, что могут повлиять на метрики) и уведомить о ситуации дизайнера (что замечания с низким приоритетом будут поправлены в другой задаче) — как раз в этой ситуации и важна та самая коммуникация, о которой я пишу. Если её не настроить, тогда и появится то самое узкое горлышко. Работаем с дизайн-ревью с Нового года и пока без узкого горлышка.
Ксюша, извините! Но КДПВ и начало текста неразрывно связались в моем восприятии :)
именно так
На скриншоте из джиры фамилии заблюрены так, что их без проблем можно прочитать.
А вроде дизайнеры :) или так было задумано?
Ксения спасибо за то, что поделились вашим подходом, было очень интересно узнать о нем. Думаю это реально может повысить качество продукта и добавлять мотивацию всей команде. Вы прекрасно изложили его суть, преимущества и недостатки, как его внедрить. Я уверена это поможет легко принять решение использовать этот дополнительный этап в разработке или нет.
Ксюша, спасибо за статью. Было интересно узнать, как это вообще выглядело с вашей точки зрения и почему возникла идея дизайн-ревью.
Так как я как раз нахожусь внутри этой команды, могу сказать, что изначально такой процесс, конечно же, воспринимался негативно, но с точки зрения продукта - это правильный процесс. К нам больше не приходит бизнес после выкладки и не говорит: а тут не как в дизайне => даже если у нас может незначительно увеличиваться Time to market, в долгосрочной перспективе такой подход лучше, так как впоследствии не нужно вносить правки.
Надеюсь когда-нибудь, вы вырастете профессионально настолько что повлияете на современные тренды прикрываясь предлогом Time-to-Market,выкидывать всю валидацию продукта из флоу. Реальность же такова: сделать побыстрее, получить оплату, и взять следующий заказ. Видите в этой цепочке качество? Раз не написано значит и не нужно, таковы реалии.
Спасибо за статью, клёво!
Так получилось, что я немного работал по обе все разные стороны баррикад и хочу от души порекомендовать: не делайте «дизайнерские» шаблоны для процессов и документов, которые уже реализованы вашей основной системой управления проектами (Jira и т.п.). Это создает лишние «источники правды»: двойную структуру статусов, приоритетов, уйму дополнительной бюрократии, путаницу и расхождения. Разработчикам, как правило, не нужна «красота» в тикетах, им гораздо удобнее оперировать обычным флоу. У QA всегда есть свои стандартизованные форматы баг-репортов c acceptet/expected result, доп информацией по контексту и т.п. Поверьте, будет гораздо, гораздо, гораздо лучше, если вы обучите дизайнеров следовать этому флоу репорта, а не создавать новые, да еще в Фигме.
Я сам несколько раз наступал на эти грабли. Делал красивые шаблоны эстимейтов, ретроспектив и всего на свете. Хорошо продуманные, даже частично автоматизированные. Спустя полгода-год все они превращались в тыкву, потому что жизнь идет, процессы меняются, заполнять в двух местах неудобно, а поддержка актуальности макетов требует времени, которого всегда нет. Если вы не готовы переносить все функции Jira в Фигму или держать отдельного «дизайнера документации», то лучше не множить сущности.
Макеты не предназначены для управления проектами. Они не поддерживают двойную синхронизацию с тикетами. Вы из картинки ссылаетесь на тикеты, статусы и прочие данные, которые меняются. Склеили два тикета на стороне Jira - в «дизайнерском документе» оказались битые ссылки. Поменяли названия статусов – в «дизайнерском» остались старые. И т.п.
Причем идея «удобных» шаблонов рано или поздно приходит в каждый отдел, и начинается ад, потому что менеджеры прикрепляют к тикету списки в Notion, аналитики – в Excel, CEO - фото исписанной салфетки из Мишлена и т.п. Гораздо лучше поступиться красотами и мнимыми удобствами и следовать стандарту той общей системы, которая используется для управления проектами.
Upd: Упс, получился какой-то менторский коммент. Это не негатив, я просто слегка увлекся описанием наболевшего из практики :) Во всем остальном статья прекрасна!
Как дизайнеры тестируют, или Что такое дизайн-ревью