Как балансировать между скоростью и качеством? ⚖️

Спойлер: ответ на этот вопрос я ищу до сих пор.

В процессе выполнения сложной работы разработчики часто приходят ко мне с мелкими вопросами из задач, которые я делал месяцы назад.

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

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

Как итог: качество решения мелкого вопроса страдает. Конечно, это происходит далеко не всегда, но риск велик.

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

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

С другой стороны, «медленно и качественно» тоже не лучший выбор.

Вспомнил историю про XHTML 2.0: его создатели потратили более 5 лет на разработку языка нового поколения, который в итоге оказался ненужным.

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

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

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

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

Я продолжаю искать баланс, а что думаете по этой теме вы?

Почему я пишу в блокнот, а не в гаджет?

После окончания института все дела я стал вести в блокноте. Так и сформировалась привычка, которая со мной до сих пор.

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

Потом из книг и курсов я узнал про Bullet Journal — систему ведения дневника, которая структурирует цели и задачи на день, неделю, месяц и год.

Я попробовал этот подход, и мне понравилось. Оставив оглавление и методику маркировки, я создал свою адаптированную версию, которой пользуюсь и сейчас.

Все свои дела я отмечаю:

⚫️ Для каждой поставленной задачи и для события, которое нужно не забыть. Если есть время, указываю его вначале;

✔️ Для выполненных дел;

➡️ Для переносов.

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

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

Писать стараюсь ежедневно, но насильно себя не заставляю. Иногда не веду записи целый месяц и не корю себя за это — бывает 😅.

А как вы ведете свои дела? В блокноте? В телефоне? Какое приложение?

Почему эффективнее записывать дела в блокнот?📝

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

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

Участники исследования Токийского университета создали вымышленное расписание на два месяца и отвечали на вопросы по нему (Когда произойдет одно из событий, какое случится раньше и др.), параллельно проходя функциональный МРТ.

Результаты такие: те, кто делал задание от руки, справились на 25% быстрее других.

Почему так происходит?

Ученые Норвежского университета с помощью метода ЭЭГ выявили различия в мозговой активности при письме от руки и печатании на клавиатуре.

Каждый участник написал 15 слов от руки и те же 15 напечатал. Оказалось, что за этими действиями стоят разные когнитивные процессы.

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

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

Что думаете на этот счет?

Топ 3 причины, по которым люди все упрощают.

Замечали, как много сейчас текстов с такими заголовками («3 способа...», «5 лайфхаков...») в интернете?

Посты, которые дают «волшебную таблетку», пользуются спросом, а сложные научные статьи большинство не читает (и я в том числе)

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

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

Упрощение — это еще и про умение расставлять приоритеты, говорить «нет», не распыляться на сотню недостижимых целей, а сосредоточиться на главном.

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

Или вот пример:

Дизайнеру говорят: «Форма регистрации слишком сложная, упростите её».

Он может решить, что проблема только в количестве полей, и удалит всё лишнее: номер телефона, дата рождения, подтверждение пароля. В итоге форма станет минималистичной: только email и пароль.

Но на практике это может привести к новым проблемам:

❌ Пользователи начнут ошибаться при вводе пароля, так как нет подтверждения;

❌ Без номера телефона будет сложно восстановить доступ;

❌ Упрощенная форма может не соответствовать требованиям бизнеса, например, для аналитики.

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

Поэтому упрощать важно и нужно, но далеко не всё. Пусть некоторые вещи так и остаются сложными - миру еще нужны хорошие специалисты 😉

Личный опыт проведения Демо Дизайна

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

Но обо всем по порядку.

1. Организация

Моя задача была не только собрать всех, кто хотел рассказать о проделанной работе, но и помочь им с докладами и замотивировать на клевое выступление.

На подготовку был всего один прогон. Там мы окончательно определялись с целями выступлений, корректировали презентации и в целом давали фидбэк друг другу.

Тренировались укладываться в тайминг: 7 минут на выступление.

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

2. Само мероприятие

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

Демо шло 2 часа — восемь выступлений и 10 минут перерыва в середине.

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

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

В результате едва уложились в отведенные 1 час 50 минут.

3. Итоги

💡 Всегда сохраняйте спокойствие.

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

💡 Закладывайте достаточно времени.

В этот раз вопросов было больше, чем планировали, и пришлось где-то срезать углы. Буду учитывать в следующий раз и выделять минут 10 запасных.

💡 Взаимодействуйте с аудиторией.

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

💡 Шутите!

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

Рекомендую вам проводить подобное мероприятие раз в 3-6 месяцев.

А вот зачем команде нужны демо — это тема отдельного поста. Ставьте 🔥, если интересно.

Зачем проводить дизайн демо?

Демо — один из способов показать результаты работы продуктовой команды дизайнеров и получить обратную связь.

Мне кажется, что это важно проводить по нескольким причинам:

🔼Прозрачность внутренних процессов.

Регулярные демо повышают доверие к продуктовой команде.

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

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

🔼Обмен опытом.

Часто сотрудники разных отделов или продуктов не знают, что происходит за пределами их зоны ответственности.

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

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

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

🔼Мотивация и признание.

Каждый хочет видеть, что его вклад в общее дело ценят.

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

🔼Развитие софт скилов.

Умение выступать на публике и рассказывать о своих успехах — сами по себе полезные навыки, для дизайнеров в том числе.

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

Не делай несколько вариантов дизайна! ❌

Часто заказчики просят сразу несколько вариантов дизайна, чтобы было из чего выбирать.

Я считаю, что в большинстве случаев одно варианта достаточно.

❗️Важное уточнение: Достаточно, чтобы показать заказчику❗️

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

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

К заказчику нужно идти с ним, с идеальным вариантом. В крайнем случае с двумя, если есть сомнения.

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

🚩Но запомните красный флаг: если заказчик говорит: «Сделайте мне три варианта дизайна интерьера», то это изначально плохо поставленная задача.

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

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

В таких случаях, когда человек сам не знает, чего хочет, от дизайнера многое зависит.

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

Представьте ситуацию, что дизайнер потратил кучу сил на три дизайна интерьера — минимализм, лофт и бохо — а заказчик давно мечтал о гостиной в скандинавском стиле.

🔭Я, конечно, специально утрирую, но вы поняли суть.

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

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

Платить, чтобы работать: уроки своего бизнеса

Вспоминая годы предпринимательства, у меня до сих пор хорошо отпечатался момент-просвещение.

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

С еще одним открытием я столкнулся, когда появились первые сотрудники. При расчёте прибыли я внезапно осознал, что каждый человек в моей таблице Excel превратился в... инструмент. Как бы цинично это ни звучало, но сотрудник должен был приносить прибыль выше своей зарплаты. Желательно раза в 2+ больше.

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

На построение этой системы ушло полгода проб и ошибок. И было нелегко, особенно в периоды, когда прибыли не было.

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

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

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

Мой совет дизайнерам: попробуйте мысленно «стать владельцем» компании, где вы работаете.

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

Ты знаешь меньше, чем тебе кажется

Недавно наткнулся на теорию Ричарда Фейнмана про изучение чего угодно. Мне показалось, что она пересекается с множеством других теорий (в том же Learning how to learn это было), но более лаконично доносит суть.

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

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

Техника Фейнмана как раз помогает с этим бороться. Концепцию он свел к четырем последовательным шагам:

1️⃣ Выберите тему и начните ее изучение с общих понятий. Чтобы не закапываться сразу, лучше начать с основ и идти по нарастающей.

2️⃣ Объясните тему, будто учите другого. Попробуйте выписать все, что знаете, на лист, не подглядывая, или объясните тему не разбирающемуся человеку.

3️⃣ Вернитесь к изучению и устраните пробелы. Возвращаться к исходному материалу — это нормально, для изучения чего-то сложного нужно несколько подходов.

4️⃣ Упрощайте формулировки и приводите аналогии. Главный признак понимания — способность объяснить сложное простыми словами.

Последний пункт, кстати, перекликается с моим прошлым постом о сравнениях в переговорах. Если вы владеете темой, то объясните ее без лишних терминов и с понятными аналогиями.

Техника подходит для изучения и для подготовки к выступлениям. Помогает оценить простоту информации: если не получается заменить научные термины на что-то попроще — то нужно копаться в теме дальше.

Негативный фидбэк обиден для всех

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

Большинство людей обижаются, даже если говорят, что им «всё равно».

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

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

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

Пока ты еще новичок, любой фидбэк на вес золота — только он сделает из тебя профессионала. Я в свое время не сдался😎

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

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

Переговоры — не в нужде

Представьте ситуацию: приходит клиент с новым проектом, а у вас и своих работ достаточно. Так как потребности нет, вы повышаете цену в 1,5 и даже 2 раза, в надежде на то, что человек откажется. Но он соглашается на ваши условия.

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

Чем сильнее нужда, тем слабее положение. Опытный переговорщик это сразу замечает и, пользуясь ситуацией, диктует свои условия. Вам надо? Значит, подстраивайтесь.

Что делать, если вы в нужде?

Этот подход я в свое время узнал из Бюро Горбунова, и они советуют заменить «надо» на «хочу».

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

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

А это я бы добавил от себя:

🎯 Прикиньтесь.
Даже если других вариантов нет, сделайте вид, что они есть. Притворитесь, будто сделка важна, но не критична, тогда собеседник начнет воспринимать вас иначе.

🎯Установите границы.
Определите «нижний порог» условий, на которые вы согласны. Если вы заранее знаете свою черту, будет проще отказаться от невыгодного предложения.

🎯Помните о самоуважении.
Иногда лучшая сделка — это та, что не состоялась. Заранее подумайте: не пожалеете ли вы потом, что согласились на такие условия? Может, лучше вовремя остановиться и сказать нет.