И вместо Чтобы: слабая связь

И вместо Чтобы: слабая связь

Союзы «чтобы», «поэтому» и «если» — самый простой способ показать зависимость одного факта от другого. Но слишком топорный.

Напишите email, чтобы получить подарок.

Тут всё строго. Не написал email — не получил подарок. Не получил подарок — значит, не написал email. Мозг воспринимает такое предложение за следствие (не очень корректно).

Иногда причинную связь не хочется подчеркивать. Тогда поможет союз «и».

Организуйте кошке теплое место для сна, и она будет вам благодарна.

Последовательность есть, но она неявная. Коша не обязательно будет благодарна. Кошка вообще никому ничем не обязана.

С заходом солнца принесите жертву, и солнце снова взойдет.

А что если солнце восходит само по себе? Но мы и не говорили, что эти события связаны. Где там «если» или «чтобы»? Ручки-то вот они.

Ок, ближе к реальности. Сравните:

Купите диван-кровать и наслаждайтесь уютом-комфортом.

и

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

О таланте

О таланте

О таланте. Таланте и стае. Знаю полсотни талантливых ребят, тех кому дано природой, космосом, родителями, средой, умение видеть в своем деле больше и глубже других. Все — сложные. Но видел я и как сложно бывает таким людям попадать в среду людей и задач не обремененных сложностью. Талантливый всегда в сомнении, в понимании промежуточности любого успеха и жестоком давлении на самого себя.

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

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

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

4 правила хороших видео

Сегодня делюсь кусочком нашей внутренней документации о том, как записывать понятные для коллег видео.

Когда хочется продемонстрировать баг, нужно показать результат работы по задаче, показать как работает интерфейс — лучше говорить, чем писать. Чтобы передать мысль быстро, а не ждать назначенной встречи, мы прибегаем к «лумам» — коротким видео, записанным при помощи https://useloom.com.

Чтобы лум сэкономил время тебе и коллегам — соблюдай простые правила:

— Не молчи. Хороший лум — это не урок из скучного курса, а живой рассказ живого человека. Когда ты молча возишь мышкой по экрану — это понятно только тебе.
— Включи камеру. С живым человеком гораздо приятнее общаться, чем с его экраном. И пофиг, что на фоне любимая рюмочная — живое общение всё компенсирует.
— Не тяни время. Если твое видео можно уместить в минуту — не записывай пятиминутный сериал. Цени время коллег.
— У готового видео обязательно укажи заголовок. Когда твоя проблема называется «HTTP://LOCALHOST:3000», её не очень хочется решать. Клёво — когда тема понятна сразу: «Не отправляется заказ с дробной ценой», «тормозит загрузка картинок» и т.д.

У многих компаний два основателя

У многих компаний два основателя

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

Сейчас у Nimax целая команда руководителей, каждый из которых партнер в своем подразделении. Но долгое время мы с Максимом управляли компанией вдвоем. Более того, мы еще и учились в школе, а затем в институте вместе. А сейчас живем в одном доме и дружим семьями. В общем, мне есть что рассказать про взаимоотношения партнеров в проекте.

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

Еще у меня накопился целый список других проблем, которые мы когда-либо обсуждали с коллегами из других компаний:

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

Знакомо? Ну да, проблемы у всех одинаковые 🙁
Можем разобрать некоторые из этих ситуаций — напишите какие.

Про адаптацию стажеров и младших специалистов

Наш руководитель веб-направления Таня Аладина интересно написала про адаптацию стажеров и младших специалистов:

— Для себя сделала вывод про младших специалистов, который был для меня не очевиден ранее. Младшие специалисты могут работать там, где в рамках их этапа работы они будут действовать с опытным специалистом. Например, когда младший делает верстку на реакте, а затем за ним старший пишет логику js. Или если старший делает дизайн-концепцию, а младший помогает нарисовать внутреннюю страницу, которая затем проходит ревью и подтверждение со старшим, при этом за весь результат отвечает старший.

Но вот в ситуации, когда младший целиком сдает свой этап работы сам, даже если предполагается ревью — есть сильный риск упасть в качестве. Самостоятельно – младшим должна доставаться работа начального уровня сложности. Младшие менеджеры, ответственные за проект целиком — довольно опасная ситуация. Пока не придумала, как можно продюсеров соединять в пары.

Прототипирование сложных интерфейсов с точки зрения того, как оптимизировать и учесть всё

Прототипирование сложных интерфейсов с точки зрения того, как оптимизировать и учесть всё

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

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

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

Вот вы скажете, что это:
— Прописные истины и все должны так работать.
— Ничего нового, давно всем известные вещи.
— Вы думаете, что это охуенно и преподносите всё как академические знания.

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


За 10 лет работы с самыми разными дизайнерами и в самых разных продуктах и проектах я такого подхода не видела ни разу!

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

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

Я считаю, что это полная чушь.
И уровень 99% дизайнеров в России сейчас именно такой — я за красоту, а ты лучше знаешь свой продукт — продумывай всё сам.


В статье (https://bit.ly/2XG2B7V) те критерии качества дизайна интерфейсов, которые я начинала писать здесь.