Конспект: "Как дизайну и разработке найти общий язык" (ч.1)

💳 поддержать мои гайды, лонгриды и просто задонатить на кофе - 5536913954129132 (Тиньк)

Это второй выпуск рубрики "Конспект" (первый - тут), в которой я буду публиковать сюда интересные материалы с краткой выжимкой.

Итак, сегодня принесла вам статью "Отрицание, гнев, торг: как дизайну и разработке найти общий язык".

❗️Статья очень большая, поэтому постов-выжимок будет два.

Почему я вообще принесла эту статью

Везде, где я работала, UI/UX-дизайнеры не были включены в продуктовую команду разработки, они жили отдельно, своими дизайнерскими командами со своими внутренними процессами. Контакт между дизайнерами и всеми остальными выглядел примерно так: "вот вам макеты, и живите с ними, как хотите".

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

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

Теперь выжимка (ч.1)

🟣основные боли разрабов при взаимодействии с дизайнерами:

🔘 неполные и неконсистентные макеты (не хватает экранов/состояний элементов/сообщений об ошибке или успехе/лоадеров);
🔘 вместо компонентов из дизайн-системы (если она есть), просят кастомные компоненты без объяснения причин;
🔘 дизайнеры не понимают ограничений разработки и рисуют "красивое";

🔵 основные боли дизайнеров при взаимодействии с разрабами:

🔘 реализуют макеты с очевидными багами, которые невозможно не заметить;
🔘 разрабы не вникают в макеты на этапе концепта (если им показывают) и заранее не указывают на ограничения;
🔘отказываются что-то делать, потому что это "слишком сложно/невозможно" (а потом оказывается, что и возможно, и не сложно);

❤️ что нужно улучшить, чтобы порадовать всех #1: делать больше совместных грумингов, чтобы разработка могла посмотреть на макеты несколько раз до того, как их полностью согласуют с продактами и C-lvl. Это уменьшит количество сложных ситуаций и переделок;

❤️ что нужно улучшить, чтобы порадовать всех #2: делать дизайн-ревью готового фронтенда заранее, а не за день до релиза, чтобы ревью и починка багов не делались с горящей жопой и с риском не выкатить релиз;

🟢 что отдельно можно улучшить, чтобы порадовать разрабов:

🔘если есть дизайн-система, стараться все, что можно, делать с ее помощью;
🔘стараться заранее продумывать все состояния компонентов и интерактивных элементов (ховеры, лоадеры, сообщения об успехе/ошибке, темную/светлую тему - если есть итд);
🔘повысить грамотность дизайнеров в плане ограничений платформ, чтобы не рисовали невыполнимое;
🔘указывать отдельно в фигме и в чатах, что в макетах что-то изменилось;

🟡 что отдельно можно улучшить, чтобы порадовать дизайнеров:

🔘 помочь дизайнерам повышать упомянутую "грамотность": организовать локальные внутренние ликбезы/митапы, делиться обучающими материалами;
🔘 разрабам - поучиться пользоваться фигмой, посмотреть пару туториалов (или почитать эту статью);

В следующей части выжимки будут более подробные и предметные рекомендации на уровне процессов, которые вы можете предложить своим командам.

Про перфекционизм

💳 поддержать мои гайды, лонгриды и просто задонатить на кофе - 5536913954129132 (Тиньк)

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

Пока ты в школе, это более-менее работает: оценка результатов прямолинейная. Задача или решена верно, или нет. Сочинение или написано с ошибками, или нет. Стихотворение или выучено, или нет. А потом мы вырастаем, находим работу, в данном случае - приходим в айти, и начинается трындец.

Как только мы делаем что-то сложнее "поправить мелкий баг", вляпываемся в сразу несколько проблем:

🟣 никто ничерта не знает, что такое "сделать идеально". Есть бест-практисы, но даже об них с энтузиазмом ломают копья убеленные сединами айтишные деды. Попробуйте найти хоть один концепт или технологию, вокруг которых не было бы десятков эпичных конфликтов: говно оно или не говно - не выйдет;

🟢 более того, очень хорошее в моменте решение может отстрелить тебе жопу через несколько месяцев. А если в этом самом моменте начать защищаться от всех "а что, если", нагородишь таких переусложнений, что потом не разгребет никто;

🟡 требования регулярно меняются. То, что было очень хорошим вчера, сегодня приходится сносить нафиг - фича должна работать иначе, хотелки бизнеса изменились;

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

Альтернатива перфекционизму - подход "достаточно хорошо"

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

Что такое "достаточно хорошо" на примере. Представим, что мы - фронтенд-разраб, и у нас задача - сделать модальное окошко. "Достаточно хорошо" будет, если:

🔘 мы соблюли визуальные требования - модалка с начинкой соответствуют дизайну;

🔘 мы соблюли функциональные требования - модалка открывается по клику на нужную кнопку, закрывается, показывает верную начинку, начинка тоже работает;

🔘 мы учли типовые продуктовые корнер-кейсы - поддержку разных браузеров (если надо), поддержку разных типов устройств (если надо), ситуацию, если "начинка" не прогрузилась/ее слишком много, например, 100 абзацев текста (это называется проверкой на переполнение контентом);

🔘 мы сделали аккуратный код без видимых костылей, заложили базовую автономность компонента с модалкой (не прибили его гвоздями к текущему компоненту), учли самые типовые корнер-кейсы, соблюли код-стайл проекта (или сформировали пак предложений в случае необходимости от него отступить);

🔘 на всякий случай, перепроверили свою работу перед сдачей;

Все, вы великолепны!

А если я вижу, как улучшать и улучшать дальше

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

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

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

Помните главное. Лучше сделать что-то, пусть не идеально, и разобрать свои ошибки по итогу, чем сделать идеальное "ничего"

Как критиковать, чтобы это было конструктивно

Дисклеймер. Я не буду в этом посте рассказывать про сэндвич-концепт ("похвали" - "поругай" - похвали"), сосредоточусь на другом.

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

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

Дисклеймер #2. Я не говорю о ситуациях, когда собеседник вас достал, и вы хотите защитить свои границы. Это уже не критика и выходит за рамки поста.

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

Хорошо, а как на практике?

Перед тем, как практиковаться, надо честно ответить себе на вопрос: зачем вы человека вообще критикуете? Вы хотите ему добра или покрасоваться? Вы хотите помочь ему вырасти или пнуть, потому что а чо он такой неидеальный? Если ответы вторые - положите человека на место и не практикуйтесь.

Если же первые, вот вам основной фактор, делающий критику полезной: проверять все тезисы своего фидбека на "это поможет вырасти?".

Что вырасти не помогает

🟣 любые переходы на личности (критика человека, а не идеи/результата). Приведу примеры из фидбеков на реальных мок-собесов с ютуба: от "Ну для человека без формального образования достаточно хорошо" до "Когда говорю с вами, ощущение, что общаюсь с ChatGpt" (речь не про то, что кандидат списывает, а про манеру разговора);

🟣видимые обесценивания. Тоже из реального мока: "вообще, эта задача должна быть решена за 2 минуты, и то, если ночь не спать". Задача уже не решена за это время, хотя собеседуемый выложился на полную. От того, что ткнешь человека в его несовершенства таким образом, легче никому не будет;

🟣отсутствие конкретики. "Не, ну плохо сделано" - не конкретика. Совершенно неясно, что с этим замечательным фактом делать.

Что вырасти помогает

Связка "что неправильно -> почему это неправильно -> как правильно -> какие дополнительные шаги сделать, чтобы улучшить (опционально)".

У критикуемого по каждому пункту должно остаться на руках 3 вещи: что именно не так, почему оно не так и как сделать, чтобы было "так".

Например: "Решение задачи, на мой взгляд, неоптимально, потому что <... список причин ... >. Чтобы было оптимально, нужен подход такой-то и потому-то. Почитай Васю Пупкина, он в своих статьях отлично это раскрывает, можно еще добить книгой Пупки Васина, если хочется".

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

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

Важно: следите за состоянием критикуемого. Если он уже сидит с совсем сложным лицом, возможно, пора остановиться и продолжить позже.

Когда давать критику, чтобы было конструктивно

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

2️⃣ когда это подразумевает контекст (например, вы ревьюите коллегу или проводите мок-собес);

Если меня не просят, а хочется покритиковать?

Говорим: "Мне кажется, я могу помочь улучшить твой результат. Хочешь?". Если ответ положительный - отлично, критикуем, если отрицательный - тоже хорошо, что вы не потратили зря время.

Вот я и рассказала, что хотела. Гарантирую, эти правила сберегут и вам, и окружающим много сил и нервов.

И раз уж заговорили о тимлидах

Я тут смотрю доклад Саши Кирсанова на тему того, должен тимлид кодить или нет. И это тот случай, когда остро не согласна с примерно 95% тезисов автора.

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

Если вкратце, основной пойнт Саши: "тимлид должен быть самым сильным техническим специалистом на проекте, должен много и плотно кодить, только тогда он будет авторитетом".

Моя же позиция: тимлид не должен кодить, отвалите от тимлида.

Почему так думаю:

1️⃣ навыки тимлида не падают людям с неба просто за то, что им дали должность. Это здоровенная отдельная область знаний, как фронтенд или дизайн.

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

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

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

3️⃣ далее, у тимлида есть, вообще говоря, круг своих обязанностей.

Работа с командой: регулярные 1-1, организация процессов (не путать с миллионом созвонов), организация роста сотрудников, решение всяких околомотивационных вопросов.

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

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

Я написала это в тви и получила стопку типичных возражений:

✖️а кто тогда будет охренительно кодить и контролировать качество?

Сеньоры, технические грейды выше сеньора (сеньор+, стафф), архитектурный комитет, техлиды.

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

И не надо путать тимлида и техлида, это разные карьерные треки.

✖️ а как тогда зарабатывать авторитет?

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

✖️а чем это отличается от проджект менеджера?

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

Тимлид - про команду, про ее внутренние процессы, про то, чтобы всем было комфортно, все выполняли свои функции, росли, чтобы у всех всё было: от технических ресурсов до повышений вовремя.

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

❗️Анонс моего благотворительного ивента для Junior Frontend и верстальщиков (с опытом тоже можно)

🛑🛑🛑 UPD. Набор временно приостановлен (кто уже успел написать - тем отвечу)

Делаю небольшой благотворительный онлайн ивент, чтобы помочь джунам получить проект в портфолио и собрать немного денег в пользу НКО "Ночлежка" (или любого зарубежного аккредитованного НКО, если вы не в РФ).

📘 Что будет

🔸 мы соберемся 4-5 командами по 4 человека (можно заявиться и одиночкой, и несколькими людьми: команды я соберу);

🔸 после аппрува участия участник вносит 800 рублей сразу в "Ночлежку"/зарубежное НКО (❌мне ничего переводить не надо) и присылает чек;

🔸 я присылаю командам красивый макет средней сложности в Figma;

🔸 мы тратим выходные в околохакатанном формате и реализуем макеты в HTML/CSS/JS (без фреймворков);

🔸 я делаю публичное код-ревью всем командам;

После ивента вы сможете продолжить работу сами: или в команде, или лично, если захотите.

🗓 Когда будет

Ивент будет длиться все выходные 28-29 сентября, с 10:00 утра субботы до 17:00 воскресенья (потом - смотр работ и ревью)

⭐️ Кто может участвовать

Все, у кого есть базовые или выше знания HTML/CSS/JS (JS - на уровне "подключить готовую библиотечку"). Фреймворков не будет.

Допускаю и ребят без опыта вообще, и опытных верстальщиков.

✉️ Как участвовать

🔸написать мне в личку (@natti_davydova) письмо, начать его с "хочу участвовать в ивенте", обязательно рассказать там, какой у вас опыт (чтобы я смогла сделать сбалансированные команды);

🔸заявляться можно и по одиночке, и сразу несколькими людьми;

🔸после аппрува вашего участия, вы вносите 800 рублей в НКО "Ночлежка" (или $10 в любое аккредитованное НКО, если вы не в РФ) и присылаете мне чек;

🔸 до 22 сентября включительно будут сформированы команды, и вы успеете познакомиться, подготовить репозиторий для работы и договориться по стеку (будут ли препроцессоры, tailwind итд);

🔸28 сентября получите инструкции, и начнем;

🙁 А если у нас ничего не получится?

🔸 по организационным вопросам я буду поддерживать вас в течение всего ивента;

🔸 даже если у вас не получится закончить макет, вы получите код-ревью и понимание, куда самостоятельно двигаться дальше;

В любом случае, вы унесете с собой новый опыт, красивый уникальный проект и получите возможность поработать в команде (либо поменторить новичков и возглавить команду);

Самый добрый, искренний и полезный психпросвет-блог

В этот раз - не реклама, а исключительно по любви. Хочу рассказать про блог моей чудесной подруги Леры Зелёной - "Рефлексант".

Лера пишет потрясающе честно, увлекательно и незанудно о том, как справляется с депрессией и СДВГ, как учится отдыхать и отключаться от бесконечной перфекционистской гонки, как исследует свой внутренний мир и что из этого выходит.

Я нашла ее блог несколько лет назад и после пары месяцев запойного чтения очень захотела с Лерой подружиться: настолько славный она человек, настолько ее мысли и ценности со мной резонируют. И вышло же! Я горжусь тем, что дружу с ней ❤️

Знаете, что мне особенно нравится в "Рефлексанте"? Он не только про рост и активное развитие, он и про поражения тоже. Если что-то валится из рук, если случаются откаты, это не скрывается от читателей, нет иллюзии бесконечного успеха. Здесь блог живого человека со своими сложностями, неуверенностями, страхами, победами и провалами.

О чем вам может быть интересно почитать тут

🟣о том, как преодолевать жестокое и грубое отношение к себе, привычное с детства, к чему приводит абьюз себя и постоянное тыканье палочкой, и о том, как гарантированно выгореть;

🔵 о том, как сложно, но важно принимать себя внешне и внутренне в культурной парадигме, призывающей постоянно искать в себе недостатки, о ценности самопознания и о том, как не загнобить себя, когда неминуемо сравниваешь себя с другими;

🟢 о том, как учиться отстаивать свои границы, когда ты мяконькая булочка, о том, что все мы иногда - те еще жопники, и о том, что можно (а порой, и нужно) двигаться вперед без мотивации и вдохновения, просто делать шажок за шажком;

🟡 о том, как учиться отдыхать, если привык бесконечно гнаться хомяком в колесе, о том, что хотеть поныть - нормальная и здоровая история, и как сохранять в себе вкус к жизни;

🟣 о психпросвете в общем: о том, что у депрессии нет лица, и люди с диагностированной депрессией не всегда лежат лицом в стену, о "налоге на СДВГ и о том, что делать, когда тревога сжирает изнутри;

🔜 Подписывайтесь на Лерин "Рефлексант", будем вместе удерживать кукуху и справляться с жизненными челленджами

Вас не могут просто так сдернуть с удаленки (по ТК)

Один из способов давить на сотрудника, чтобы он ушел без выплат - угроза дисциплинарными взысканиями. Что тут самое простое пытаются сделать: "отменяют" удаленку, дескать, с завтрашнего дня выходи в офис, а то вменим тебе прогулы, впаяем дисциплинарки и уволим по статье.

Что вам важно помнить

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

🟡 если у вас допник к ТК с удаленкой (бессрочный), его тоже не могут отозвать в одностороннем порядке, тут та же история с соглашением сторон;

Когда вызов с удаленки без согласия возможен

🟣 если вас предупредили за 2 месяца + "если в компании произошли организационные и технологические условия труда, которые существенно изменили условия труда" (а значит, вас единственного из команды вытащить не смогут, кроме того, компании понадобится еще доказать эту самую смену условий труда);

🟢 если перевод на дистанционку был временный, с фиксированной датой окончания в договоре/допнике;

А если нет ни договора с удаленкой, ни допника

Тут есть такой концепт, как "фактически сложившиеся отношения".

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

Трудовая инспекция очень заинтересуется тем, что "отношения" сложились, а договора к ним нет, и вменит компании с вами этот договор подписать.

❗️Традиционно, напоминаю: если вас увольняют не по вашей воле, ничего не подписывайте на месте, всегда берите время посоветоваться с юристом

🔜 Еще очень, очень советую культовый доклад Витали Шароватова про правовые нюансы увольнений.

Запоздалый дисклеймер

Я никого не принуждаю "качать права", если не хочется. Просто стараюсь дать опции, которые помогут вам уйти в сложной ситуации по соглашению с выплатами. Что делать дальше с этими знаниями, вам решать.

Другие мои посты про увольнения

- 3 правила, которые спасут вам нервы и деньги, если вас пытаются уволить с работы (по ТК);
- Про увольнения с ГПХ-договора;
- Поговорим про плохие увольнения;

Завершилась активная часть благотворительного ивента для джунов

В конце августа я анонсировала небольшой благотворительный ивент для джунчиков-фронтов в пользу "Ночлежки".

Через 2 часа ребята закончат двухдневную разработку макета на HTML/CSS/JS (без фреймворков), и начнется презентация работ.

Заходите посмотреть, какие у них классные результаты получились ❤️

🗓 стартуем сегодня, 29 сентября, в 18:00 по Мск

🎙 запись трансляции останется по той же ссылке

➡️ больше об ивенте тут

Ревью работ благотворительного ивента для джунов фронтов, ч1

Сегодня будет трансляция первой части ревью проектов ребят на HTML/CSS/JS.

❗️Важно: команды работали над проектом всего 1.5 дня. Они сделали все, что было в их силах за это короткое время. В проектах есть ошибки, и это нормально. Не надо ребят за это тыкать.

Любые нападки на проекты буду зачищать.

💫 Кому полезно

Всем фронтам, кому интересно послушать и поболтать про верстку, бест практисы и сложности

🗓 Когда будет

Сегодня, 30 сентября, в 18:00 по Мск. Запись останется!

📎 Ссылки на работы команд

Сегодня посмотрим работы 4 команд

🔸 Команда #1
🔸 Команда #3
🔸 Команда #4
🔸 Команда #6