- Лонгрид
- 3 просмотра
Как управлять качеством, не становясь бутылочным горлышком
Сорок комментариев помогают дотащить один макет, но быстро учат команду ждать разрешения лида. Разбираюсь, как отвечать за качество и не ревьюить каждую кнопку лично.
Ревью, конечно же, нужно. Но если без моего «да» дизайнер не может показать макет, это уже не контроль качества, а зависимость от свободного слота в моём календаре.
Ниже рассказываю, что команда может решать сама, где подключаюсь я и в какой момент работу лучше остановить.
«Скинь макет, я быстренько посмотрю».
Быстренько — это открыть Фигму на пять минут, а через час обнаружить, что оставляешь сорок первый комментарий к макету. На следующий день приходит ещё один макет, а потом ещё. В какой-то момент ты понимаешь, что половину недели работаешь комментатором в чужих задачках.
Следующий уровень: ты сидишь на встрече с руководством, а дизайнер пишет, звонит и снова пишет. Через час у него встреча с продактом, и ему показывать решение, но без твоего «да, ок» он боится туда идти.
Его неуверенность в секунду стала моей срочной задачей.
И я понимаю, откуда это берётся и почему руководители в этом начинают тонуть. Лид отвечает за результат и видит, что всё поедет по известному месту. Кажется, что проще сейчас написать с десяток комментов, чем потом ходить по встречам и оправдываться, почему мы сделали лажу.
В итоге ревью уже не управляет качеством. Это последняя проверка перед релизом.
Сорок комментариев — это ещё не ревью
Комментарии, конечно же, нужны. Важно не делать вид (хоть и хочется), что все взрослые люди и как-нибудь разберутся сами. А вот и не разберутся.
Но меня больше интересует не то, как дизайнер поправил этот макет, а то, что он принесёт в следующий раз.
Если я оставил коммент «покажи ошибку», а дизайнер просто дорисовал красный текст в красной плашке под полем, то он научился одному: исполнять мои правки. Почему ошибка важна и какие ещё состояния здесь есть, он мог так и не понять.
Дизайнер завтра принесёт новый макет и там снова не будет этих состояний. Можно ещё раз написать тот же комментарий, а можно наконец задаться вопросом: почему мы вообще ищем проблему в самом конце работы над макетами?
Деминг вообще писал про производство, но мысль у него простая: если качество проверяют только в конце, то вы будете бесконечно ловить уже сделанные ошибки. Мы делаем то же самое с макетами.
Если я в третий раз пишу про состояния, дело уже не в конкретном макете. Возможно, у нас просто нет общего правила. Возможно, задачу поставили так, что половину сценария никто так и не увидел. А может, одному конкретному дизайнеру просто не хватает навыка.
Комментарий один, но лечить нужно три разные вещи. Ещё один гайд не поможет дизайнеру, который не понимает сценарий, а час разбора не исправит задачу, в которой забыли про продукт.
Не всякая кнопка должна доехать до лида
Но вернёмся к ревью.
Кнопка в знакомом сценарии и новая модель доступа к данным — не одинаковые задачи. Но на ревью их частенько сваливают в одну кучку и зовут лида на всякий случай.
Чтобы разобрать эту очередь, нужно понять, что дизайнер может решить сам, а что лучше поднять выше. Я обычно смотрю на три вещи:
- что случится, если мы ошибёмся;
- сможем ли быстро откатить решение;
- как далеко разъедется проблема.
Это и есть цена ошибки, обратимость и радиус последствий. Термины можно забыть, но на три вопроса ответить всё равно придётся.
Если хотя бы один ответ выглядит стрёмно, я не успокаиваю себя двумя остальными, потому что маленькое и легко откатываемое изменение всё равно становится системным, если задевает десять продуктов.
После такой проверки становится понятнее не только, как ревьюить решение, но и кто вообще должен его принимать.
У команды получается три режима:
- это я решаю сам;
- сюда приношу варианты и объясняю, чем мы рискуем;
- здесь останавливаюсь и зову тех, чьё решение нужно.
Лиду нужно договориться об этом заранее, а не объяснять границу на сорок пятом комменте.
Локальное и легко откатываемое
Знакомый сценарий, обычный компонент, дешёвый откат. Дизайнер проверяет себя сам и показывает работу коллеге.
Если без лида здесь нельзя подвинуть кнопку, то либо правила мутные, либо в команде никто никому не доверяет. И оба варианта так себе.
Новое и спорное
Новый сценарий, конфликт целей, слабые данные или заметное изменение поведения. Здесь я подключаюсь, но не для того, чтобы выбрать самый красивый экран. Мы разбираемся, что потеряем в каждом варианте и с чем готовы жить.
Системное и дорогое
Общий паттерн, несколько продуктов, безопасность и решения, которые потом дорого переделывать. Тут уже полезно позвать людей, которые не живут внутри вашего дедлайна и смогут задать неудобные вопросы.
Если все базовые требования вдруг вылезли только здесь, мы слишком поздно открыли задачу на ревью.
Гайд не придёт и не спасёт
Ещё одна гениальная идея: если комментарии повторяются, то надо написать гайд, собрать компонент и всё рассказать на общем синке. И сразу же все пойдут читать и правильно делать (нет).
Я делал так много раз. И много раз после этого снова получал какую-то лажу.
Правила и компоненты нужны. Они снимают типовые вопросы и не дают каждый раз изобретать поле ввода. Но компонент не знает, зачем человек пришёл на этот экран, а гайд не поймёт, что реальные данные не влезают в красивый макет.
Если дизайнер ищет в документации разрешение на каждое действие, мы просто поменяли ему руководителя. Раньше он ждал меня, теперь ждёт, когда нужный ответ найдётся в гайде.
В какой-то момент всё равно придётся посмотреть на свою работу и понять, почему это решение вообще имеет смысл.
Я не хочу водить мышкой за другого человека
На ревью я почти никогда не начинаю с «подвинь сюда» и «поменяй этот блок».
Сначала спрашиваю: какую задачу решает этот экран? Что будет на реальных данных? Почему выбран именно такой путь? Что сломается, если мы уберём этот шаг?
Иногда я уже знаю, как бы сам решил задачу, но если я сразу выдам готовый ответ, то дизайнер быстро поймёт, что думать за него могу и я. Сегодня мы спасём встречу, а завтра он снова будет ждать меня перед следующим макетом.
В комментариях я стараюсь сразу писать, что именно имею в виду.
«Здесь вижу риск» — не значит «сделай, как я сказал». Риск нужно проверить и решить, готовы ли мы с ним жить. «Можно подумать вот так» — это вариант. Если изменение обязательное, я пишу об этом прямо.
В остальных случаях решение остаётся за дизайнером.
Иначе любой комментарий лида превращается в обязательную задачу. Не потому, что дизайнер согласен, а потому, что непонятно, можно ли со мной и моими аргументами вообще спорить.
«Бери ответственность» — отличный совет
Особенно если не сказать, где она заканчивается.
Дизайнеру мало разрешить принимать собственные решения. Ему ещё нужно право сказать: «Тут что-то не сходится, дальше не пойду».
В Toyota для этого есть принцип jidoka: если в процессе появилась проблема, её не скрывают до финальной проверки. Процесс останавливают и разбираются с причиной.
Мне здесь нравится одна мысль: не надо тащить проблему до конца только потому, что никто не решился поднять руку и сказать о ней.
В жизни это выглядит не очень красиво. Продакт и руководство по-разному понимают цель. Кто-то принёс идею, которая вообще не ложится в продукт. Общий компонент хотят переделать, потому что так красивее, а что будет с остальными сценариями, никто и не подумал. В такой момент кто-то должен сказать: стоп, мы сейчас не понимаем, что делаем.
Дальше начинается конфликт и, возможно, эскалация. Приятного мало, зато все наконец узнают, кто может принять этот риск и кто потом будет объяснять последствия.
До первого пожара лучше договориться:
- какие риски нельзя молча принять внутри задачи;
- кто может остановить работу;
- кому нести развилку;
- что нужно показать, чтобы принять решение.
Без этого «бери ответственность» означает «угадай, за что тебе потом дадут п*зды».
Лид всё равно никуда не делся
После всех этих договорённостей нельзя просто исчезнуть и сказать: «Ну вы же теперь зрелая команда».
Я всё ещё отвечаю за планку, общий контекст и сложные решения. Мне нужно видеть, что делает команда, иначе я просплю момент, когда старое правило перестало работать, а спорная идея уже едет в разработку. Иногда работу нужно остановить и прямо сказать: так не пойдёт, работа пока не готова.
А теперь можно открыть последние десять ревью и посмотреть:
- какие комментарии я пишу из раза в раз;
- что дизайнер мог спокойно решить без меня;
- где действительно был риск, который нельзя было оставлять внутри одной задачи.
По этому списку быстро видно, строю ли я систему качества или просто быстрее всех исправляю чужие макеты.
Команда должна уметь нормально работать, когда у меня забит календарь, я в отпуске или сижу на встрече, из которой нельзя выйти.
Если без меня всё рассыпается, значит, никакой системы я пока не построил. Я просто хорошо научился заменять её собой.
