Подписка на блог

Во всех сетях ссылки публикуются автоматически. Ещё есть Тумблер и ЖЖ.

Скорее всего нигде, кроме Твиттера вы не увидите какой-то моей активности, только линко-боты.

Анонсы новых постов иногда могут встречаться в историях в Инстаграме.

Про дизайнеров и программистов

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

И я стал замечать, что им присущи такие качества, которые не всегда можно найти в программистах (во мне в том числе). Но эти качества сильно помогают им в повседневной работе, потому я не смог удержаться и решил о них написать. Заранее договоримся, что когда я буду писать дальше «дизайнер», я буду иметь в виду «хороший дизайнер, который решает продуктовые задачи, а не просто рисует картинки».

И, да, тезисы будут повторяться и переплетаться между собой, потому что они все объединены одной мыслью:

Все равны и делают один продукт

Если вы ранее не работали с дизайнерами, то вам может показаться странным, когда они будут приходить к вам и спрашивать: «А как работает этот код?», «А ты уверен, что нужно сверстать так?», «Мне кажется, что вот этот код получился каким-то фиговым». Первая реакция: «Вааат? Чувак, иди картинки рисуй, ты чо».

Но это, конечно, неправильно.

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

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

(Д)изайнер: Слушай, а расскажи мне, как ты реализовал эту фичу?
(Р)азработчик: Тут сложное решение, поскольку у нас есть N сущностей и нужно, чтобы они вместе сосуществовали, то мы усложняем вот тут, вот здесь, вот там, а затем в конце делаем финт ушами, и ещё вот тут костыль небольшой. Можно и без костылей, конечно, но уйдёт больше времени, а продукт нужно выкатывать.
Д: Воу, какая дичь. Давай мы просто изменим интерфейс вот так, вот эту функцию чуть подтюним, и оно будет легче, не?
Р: Да, так нам будет проще.
Д: Огонь.

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

Пользователь — святая корова

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

Здесь всё очень просто. Если есть возможность как-то упростить пользователю жизнь, даже в каких-то мелочах, значит нужно это сделать. Конвертировать картиночки на сайте уменьшив их размер на 5%? Конечно! Упростить форму регистрации? Безусловно! Переформатировать текст, чтобы он лучше читался? Естественно!

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

Продукт — это одно целое

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

Здесь всегда помогает посмотреть на код со стороны, глазами человека, который только-только вошёл в продукт и не знает обо всех ваших «сделках с совестью». Обычно после этого открывается третий глаз, через который видно, что где-то плохо называются переменные, где-то неплохо бы добавить комментарий, а какие-то куски кода вообще лучше переписать и упростить.

KISS

Думаю, каждый программист знает, что такое KISS. Но это работает не только в коде (хотя и там про него часто забывают), но и в целом в продукте. Принцип можно и нужно применять к фичам.

Если так получается, что фича с какой-то стороны (дизайн, вёрстка, фронт, бэкенд — неважно) получается излишне сложной, то нужно или как-то порубить её на самостоятельные куски, или переосмыслить, чтобы с ней легче было работать. Главное в такой ситуации — не скрывать этого факта от коллег по продукту. Если дизайнер нарисовал какую-то магию, которую вам нужно сделать, и вы задницей чуете, что оно в итоге или будет лагать, или вообще со временем сломается, то не нужно тратить на её реализацию неделю, а потом разводить руками ¯\_(ツ)_/¯, мол, «ты сам нарисовал, я чо, я только исполнитель». Потому что в команде не может быть просто исполнителя. Если кто-то работает просто обезьянкой, которая пишет код без права голоса, то он явно что-то делает не так. Да, мы снова вспоминаем о том, что все равны и делают один продукт.

Тут вспоминается локальное сохранение заметок в Эгее, о котором как-то писал Илья. Как он его планировал сделать, и что в итоге получилось. Упрощение по всем фронтам налицо.

Скорее всего, невозможного не бывает

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

Это, кстати, реально крутая черта дизайнеров. Если они решили, что продукт должен что-то уметь, то они будут пытаться впихнуть эту возможность до последнего, обходя тем или иным образом все преграды на его пути. От программистов же часто слышишь: «Ой, не, это невозможно, оно не заработает». В такие моменты нужно подробно описывать, почему вам кажется, что оно не заработает, потому что, (возвращаясь к первому пункту) если вы не можете сходу сообразить, как это сделать, возможно кто-то другой сможет. Мы все далеко не идеальны, и голова у всех работает совсем по-разному.

Продукт в первую очередь

Скорее всего мы все встречались с тем, что пилили какую-то клёвую фичу сутками, а в конце оказывалось, что она не нужна. И ты такой: «Чоо? Чуваки, я ж столько времени потратил, а вы! Вам совсем наплевать на мою работу!». Конечно нет :-)

Просто продукт важнее.

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

— Что-то мне кажется, что получается какое-то дерьмо.
— Думаешь? <..спустя 5 минут..> Да, ты прав, и правда какое-то оно всё неживое. Давай откажемся от этого.
— Ээ. Чувак, ты же над этим месяц трудился. Проектировал там что-то, рисовал. А теперь типа просто выкинем? Время на ветер?
— Почему это на ветер? Значит, этот месяц был нужен для того, чтобы понять, что такая фича сделала бы продукт хуже. А раз так, то он стал значительно лучше, потому что в нём не появилось того, что превратило бы его в отстой.

И это важно: не запилить кривое решение порой лучше, чем запилить хорошее. Почему-то это мне напоминает электроны и дырки, если вы их помните из курса школьной физики.

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

Простота должна быть очевидной

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

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

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

К слову, на эту тему есть неплохая книжка — «Жалоба — это подарок» (демо-отрывок, только в нём введения больше, чем полезного текста). Она, правда, про бизнес, но примеры в ней простые и понятные.

∗∗∗

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

Подписаться на блог
Поделиться
Отправить
Запинить
1 комментарий
Илья

я бы не хотел с тобой работать после «Если завтра релиз, ещё ничего не готово, а мы сидим и правим тексты, то наверное кто-то понимает всё буквально, и его надо лечить :-)», этот мерзкий, снисходительный смайл. мне кажется ты плохой человек

Игорь Адаменко

Извините, если вдруг вас смогла оскорбить безобидная шутка, которая (в моём представлении) не была направлена в вашу сторону. Скорее в сторону вашего «абстрактного коллеги», который неправильно расставляет приоритеты. И говорящая о том, что в ваших же интересах ему это объяснить и не делать как он.

Да ещё и смайл оказался «мерзким» и «снисходительным».

Возможно, нам с вами действительно не стоит работать. ¯\_(ツ)_/¯

Популярное