Московский: Дизайн & Тимлид

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

В августе наконец-то встретились всей распределенной командой вживую — на тимбилдинге. Из разных городов прилетели в Калининград. Круто, что мы не просто ели и пили, а занимались делом. Продакты подготовили реальные задачи, а команды по 7 человек искали решения. Каждый включился и принял участие в общем деле — это сплотило сильнее любого тоста...

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

Когда задач в дизайн-долге много, выбирать становится сложно. Конечно, брать задачи можно и наугад — интуитивно решая, что сейчас важнее. Но я советую разработать структуру: так процесс выбора становится проще и прозрачнее. Хороший способ — оценивать задачи по метрикам. Например, на что они влияют: — Деньги (конверсии); — Качество (удобство использования); — Отношение (восприятие пользователями бренда). Также полезно оценивать то, какой процент пользователей затрагивает каждая бага и насколько сложно его реализовать...

По мере развития продукта начинают копиться интерфейстные проблемы, о которых никто заранее не думал. Например, добавляли фичу по одной, и интерфейс стал перегруженным. Разработчик отложил мелкую правку на потом и все забыли. На юзабилити-тесте увидели проблему, но исправить ее руки не дошли. Сюда же задачи, созданные на основе фидбэка от пользователей. 📍Все это — дизайн-долг. И чем дольше живет продукт, тем больше подобных задач появляется. Просто копить задачи в одном списке — мало. Поэтому мы действуем по шагам: 0...