VanillaTime

Я всегда выступал за максимальное упрощение. Зачем накручивать фичи, которые не помогают в достижении цели? Зачем наворачивать админку миллионом настроек, если они никому не нужны? Зачем показывать бесполезные данные, если они не нужны для принятия решения? И вот о последнем пункте я сегодня задумался. 😀 Не в том смысле, что, может, нужно вываливать все данные на пользователя и пусть сам разбирается, а в том смысле, что, казалось бы, бесполезные данные могут корректировать поведение пользователей. 😀 Сегодня я с криком Expensive Petroleum залил в свою Honda Civic 2008 больше половины бака бензина, что заставило мой счётчик расхода обнулиться. Вытирая слёзы, я обнаружил, что пока я не давлю на газ, расход не превышает 5.4 л/100 км. Что, для справки, очень неплохо. Так я и докатился до дома, нежно поглаживая гашетку, плавно и аккуратно. В то же время, когда Waze эстимирует мне время прибытия в 10 минут, голос в голове говорит: «Это мы ещё посмотрим». 😀 И если получается приехать за 9 мин. 55 сек., пусть даже и ценой проклятий других участников движения — это того стоит. Точно так же дело обстоит с этими измерителями скорости, которые не штрафуют, а просто информируют, превышаешь ли ты скоростной режим. По идее, они должны бы заставлять людей задуматься и ехать медленнее. Но если не давать людям четкий сигнал, хорошо они поступают или плохо, — получится как на одном из мостов в США, где водители школьных автобусов ставили персональные рекорды скорости. 😀 Мы, конечно, машины не проектируем, но данные, которые мы показываем на дашбордах, да и в любых других частях интерфейса, фреймят взаимодействие и вносят некоторую шкалу, по которой взаимодействие оценивается. Если хотите подстегнуть людей инвестировать — подсвечивайте потенциальную прибыль. Хотите сократить бездумные инвестиции — покажите цену риска. Среднее время выполнения задачи, просто показанное оператору, заставит его сравнивать свои показатели с эталоном, пусть это и не обязательно. А тривиальное количество минут, проведенное за прослушиванием любимой группы, может обернуться поводом для гордости. 😀 Мораль: любые данные, которые вы показываете, могут повлиять на работу пользователя, какими бы безобидными они ни были. Так что подходите к процессу с умом.

Давно не писал, потому что был занят оформлением своего пет-проекта. Не рабочего, а для души. Знакомьтесь — QRey (кЮрий). Это сервис по генерации QR-кодов и плагин для Figma. 😡 Проблема: «Плати или уходи» Началось всё с маленькой, но бесячей боли. Нужно было сгенерировать QR-код для лендинга. Задача тривиальная, гуглю. И что я вижу? Первая ссылка — плати. Вторая — вот png, а за вектор (svg) — плати. Третья — зарегайся и плати. Окей, иду в Figma. Там-то точно есть бесплатное? Ага, конечно. Три импорта бесплатно, дальше — плати. И это при том, что стандарт QR открыт! 🤖 Преодолевая гравитацию Короче, я психанул на жадных продукт-мейкеров. И решил, что это отличная задача, чтобы потренировать работу с Antigravity (aka Гравицапа) — AI-тулом из прошлого поста, который хотел пощупать в бою. Подход Antigravity (сначала ревью документации, потом исполнение) работает круто. Это как дизайн-ревью: выделяешь кусок текста, пишешь коммент, и модель переделывает код. Экономит кучу времени. Гравицапа с первого раза выдала годный прототип. Я накидал интерфейс в Figma, но подключить MCP напрямую не вышло. Решил просто скормить скриншот макета и иконки в папку проекта. Результат? Белый экран. 😅 И тут случился восторг. Я сообщил о проблеме, и агент сам открыл Chrome, зашел на localhost, посмотрел своими «AI-глазами» на белый экран, снял логи консоли и всё починил. За один шот. Самое полезное для agentic-подхода: Antigravity фиксировала запросы в Implementation plan, а потом писала Walkthrough — доку, как это тестить. 🚀 Что в итоге? Аппетит пришел во время еды. Я попросил на новый год: укоротитель ссылок (чтобы QR не был шумным); Firebase, авторизацию и хостинг; Адаптив для веба; Плагин для Figma. Ну и вместо того, что сказать «На каких облаках ты витаешь?!» всё это было подложено под ёлочку. 🎁 Забирайте, кому нужно: 1️⃣ Веб-сервис: если нужно подрезать ссылку + статистика по сканам. 2️⃣ Плагин для Figma: для генерация векторных кодов прямо в макете. 💸 Цена? Бесплатно. Плагин есть не просит, пользуйтесь на здоровье. Шорт-линки пока тоже free, пока я не уперся в лимиты по серверу. Резюме: Если у вас есть давняя боль — попробуйте решить её с AI за пару вечеров. Больно не будет, а вот интересно — точно.

Для меня было интересной неожиданностью, что Google выпустил свой Cursor под названием Antigravity. Абсолютно бесплатно и с набором интересных фичей. Также, как и в Cursor 2.0, новая IDE ориентирована на агентное программирование. То есть вы создадите узкоспециализированных помощников и заставите их работать вместе. Тут даже интерфейс похож. А вот где начинаются отличия, так это в подходе к превью: Cursor использует встроенный браузер, в то время как Antigravity тесно интегрирована с Chrome. По идее, можно поставить экстешн и Гравицапа сама будет рыскать по DOM и вносить правки в нужные кусочки. Наверное поэтому Chrome недавно обновили devtools :) Но есть ещё одна интересная штука — режим планирования. После получения указаний, Antigravity не кидается реализовывать все сломя голову, а подходит этап планирования. То есть разрабатывает стратегию имплементации, которую тоже можно править, выделив кусочек, например "pure JS, и попросив заменить его на "Typescript". Гравицапа (нравится мне слово) пересмотрит план под нужную технологию. В общем, тут что-то интересное, что можно пощупать. Cursor хоронить пока рановато, но монополия, кажется закончилась. Тем более, что Гугл посадил Antigravity на новую, более совершенную модель Gemini 3.0. А даже 2.5 работала лучше последней GPT, тягаясь только с Claude. Так что если вы вдруг все откладывали установку Cursor, то можете попробовать сперва аналог от биг G, может вам так понравится, что вы и не захотите уходить.

Всех поздравляю со всемирным днём юзабилити! 🥳 Это наш праздник, так что можно смело поднять бокалы кефира за довольных пользователей вашего продукта. Ну и в тему рассуждений о пользователях вот несколько забавных мыслей о лошадях 🎠. Все знают цитату, которую приписывают Генри Форду (хотя доказательств этому нет): «Если бы я спросил людей, чего они хотят, они бы попросили более быструю лошадь». Я сам грешен, и несколько раз использовал её, чтобы избавиться от ненужного ресёрча, когда мы делали инновационный продукт и хотели спросить пользователей «Ннннада?». Но тенденция становится нездоровой, когда все направо и налево суют её и ещё какие-нибудь доводы, чтобы доказать, что исследование не нужно, а проще просто запилить продукт. Особенно сейчас, когда проще сделать, чем не сделать. Роботы вкалывают. Но все ли понимают истинный смысл этих слов? 🤨 Ведь цитата не об отрицании исследований. Она о том, что нужно правильно формулировать вопросы. Конечно, люди склонны моделировать будущий опыт. — Вы будете использовать это приложение? — Конечно, что за вопросы! Вот только моделирование реальности и сама реальность — две разные вещи. Так что проблема с лошадью не в том, что люди знают, чего хотят, а в том, что не нужно спрашивать о желании, а говорить о проблемах настоящего. Кстати, Форд ведь не изобрёл автомобиль — они уже существовали. Что он сделал? Он понял основную боль людей: машины были безумно дорогими, их было сложно купить и содержать. Именно эту боль Форд «утолил» с помощью тотальной стандартизации и постоянного удешевления производства. Да так успешно, что всего за несколько лет решил проблему зловония от лошадиного помёта на улицах. Так что не спрашивайте пользователей о будущем. Исследуйте их боли в настоящем.

Приветики! Давненько не виделись лицо в лицо! И теперь у нас появилась возможность встретиться в Вильнюсе на AI-Jam 2.0. Вместе посмотрим, как кардинально изменился мир ИИ за последний год, и выясним, как сделать нашу работу... быстрее, выше, сильнее! Во время нашей уютной коворкинг-встречи мы поделимся на команды и сразимся в 4 разных (и не самых обычных!) челленджах. Мест всего 30, так что ловите момент! 7 ноября, 19:00 (обещаем 2-3 часа веселья!)

Следующей темой на моём менторинге будут пользовательские цели: персоны, jobs to be done и все такое. Но я задумался, не пора ли толкнуть тему дальше, ведь с момента создания концепции Купера прошло уже 30 лет? Только вот куда толкать-то? Текущие стандарты работают неплохо, ведь они так или иначе заставляют задуматься о пользовательских мотивах, а также о том, что именно им нужно сделать, чтобы достичь своих целей. И при этом, может, пора посмотреть на взаимодействие немного шире? Большинство взаимодействий не происходят в вакууме и имеют нелинейный характер. То есть, прописанные нами jobs, типа «наполнить холодильник продуктами» или «повысить ценность своего портфеля ценных бумаг» не происходят в замкнутом мире, где существует только наш интернет-магазин или инвестиционный апп. На взаимодействие влияют ещё множество внешних факторов, которые пользователь держит в голове, таких как доступные средства, уже имеющиеся продукты (греча ещё не закончилась) или экономическая ситуация, которая влияет на цену акций. Мы могли бы не усложнять систему и просто оставить пользователя 1 на 1 со своими проблемами, но что мешает нам засунуть нос «не в свое дело»? На самом деле, идея брать во внимание контекст не новая. Я ещё в бородатые годы защищал диссертацию на тему «Бессознательные аспекты личности в проектировании систем Человек-Машина-Среда». Но почему-то сегодня аспект среды постоянно проходит мимо ушей. И чтобы облегчить дизайнерам жизнь, можно использовать подход, основанный на классическом цикле управления из кибернетики, который превращает наши линейные сценарии в повторяющиеся циклы. Нет, это не Lean UX, это другое. Этот цикл состоит из четырех фаз, чтобы поддержать контекст в вашем взаимодействии: — Контроль, когда мы сравниваем текущее состояние с ожидаемой целью. — Действия, которые мы предпринимаем, чтобы добиться желаемого. — Анализ среды, которая так же, как и действия, может повлиять на результат. — Снятие показателей системы для принятия решений. И если раньше такой подход мог показаться слишком сложным, то сейчас с анализом среды отлично справляются AI-агенты, которые могут автономно собирать и обрабатывать информацию. Но для проектирования они нам могут даже не понадобится, ведь мы можем применять биологические мозги. Давайте для примера разберём таск-треккер. В классическом подходе мы бы ориентировались на какие-то такие цели: 1. Описать задачу максимально точно, чтобы дев-команда задала меньше вопросов и сделала точно то, что запросил клиент. 2. Подготовить сбалансированный спринт для работы. 3. Устраняя блокеры, обеспечить высокую эффективность команды. ... Или как-то так. Но по факту это будет только часть «Действия» в нашем цикле. Мы также можем посмотреть на окружающую среду: 😊 отпуска и текущие больничные, которые влияют на капасити спринта, 💀 будущие рамп-апы или дауны в команде, 🎂личные обстоятельства участников команды, 🧙‍♀️возможности аутсорса... Короче, много всего можно передать на этап снятия показателей и их корреляции с внешними факторами. И принять все это во внимание, скорректировав изначальные данные спринта. Таким образом, если мы будем проектировать взаимодействие только на основе цели, мы можем упустить возможность облегчения жизни пользователя. Вот такой вот парадокс. Так что всегда принимайте во внимание контекст. А как вы в своих проектах учитываете эту «внешнюю среду»? Сталкивались с тем, что классический JTBD заводил в тупик, потому что игнорировал контекст?

🙄 Забудьте о промпт-инжиниринге. Время учиться создавать контекст. Буквально вчера мы в команде обсуждали, как быстро обесценились многие курсы по промпт-инжинирингу, которые мы проходили всего год назад. Все те многоуровневые заклинания из инструкций, примеров и алгоритмов больше не дают такого разительного эффекта в сравнении с человеческой просьбой. Почему? Потому что современные LLM (вроде Gemini или Claude) уже делают эту "инженерную" работу за нас. Они научились понимать простые человеческие запросы и сами выстраивать внутреннюю логику для их решения. Зачастую даже лучше, чем мы, пытаясь запрограммировать их сложными инструкциями. На то они и зовутся reasoning моделями.🤖 Но значит ли это, что можно расслабиться и писать запросы из двух слов? Как раз наоборот. Просто фокус сместился. Вместо трюков с формой промпта, теперь на первое место выходит качество содержания. Железяки стала гораздо злопамятнее. 😈 Память золотой рыбки сменилась полноценной экосистемой: — Краткосрочная память (весь наш текущий диалог). — Долгосрочная память (куда модели могут записывать ключевые факты о нас и наших проектах). — RAG и Агенты (инструменты, которые позволяют ИИ "ходить в интернет", читать документы и получать актуальные данные). Теперь наша главная задача — предоставить модели максимально полный и чистый контекст. Здесь в полную силу вступает старый добрый принцип Garbage In, Garbage Out. Или, по-нашему: «Мусор в голове — мусор на входе — мусор на выходе». 🗑 Если вы сами не до конца понимаете, чего хотите, или не можете четко сформулировать вводные — никакая магическая инструкция не поможет. Поэтому вместо очередного курса по промпт-инжинирингу я теперь советую инвестировать в другое: 💎 Упражняться в ясном выражении мыслей (попробуйте объяснить сложную идею просто). 🙊 Расширять словарный запас (чтобы точнее передавать не только факты, но и атмосферу, и нюансы). 🏛 Учиться структурировать информацию (предоставлять данные ИИ в логичном и понятном виде). P.S. И как раз на эту тему сегодня нашел отличную статью. Очень рекомендую.

Недавние обсуждения в комьюнити заставили меня задуматься о том, что как дизайнеры мы очень часто ведём переговоры о зарплате, о сроках, о правках, но мало задумываемся о том, как это делать правильно. Сейчас очень много литературы на этот счёт, но почти все книги носят теоретический характер, основанный на теории игр или экономических моделях. Но на практике сложно применять это знание, особенно под прессингом. Однако Крисс Восс, бывший переговорщик ФБР по делам захвата заложников, написал чудесную практическую книгу, мысли из которой, я попробовал практично изложить в данной статье. Надеюсь, что она будет вам полезна и вы будете чаще достигать желаемого. ❤️ Почитать можно на LinkedIn или Medium.

Если у вас будет 15 минуток на выходных, и вам не будет чем заняться, то у меня для вас кое-что есть. Как насчёт потренироваться в локализации сайтов на Framer? Но с денюжками каждый сможет, а что если вы бедный, но шизанутый хардкорщик? А? Уверен, что таковые найдутся… Надеюсь. А иначе для кого я сделал этот короткий туториал?

Информационный шум вокруг искусственного интеллекта не утихает. В этом потоке ко мне пришла мысль, которой хочется поделиться: в продуктовом дизайне и разработке мы постоянно говорим о снижении когнитивной нагрузки на пользователя, однако с приходом эры AI мы почему-то начали делать обратное, навязчиво акцентируя внимание на технологии. 🧠 Нам пора перестать воспринимать AI как маркетинговый значок и начать использовать его как невидимый, но эффективный инструмент. Идея проста: по-настоящему умные технологии со временем растворяются в повседневности. Вспомните машинное обучение, Big Data или алгоритмы персонализации. Все они прошли путь от громкого хайпа до незаметного стандарта, который просто работает. Мы ведь не видим на навигаторе плашку "Маршрут построен на основе анализа Big Data", а Netflix не пишет подборку "Создано с помощью вашей персонализации". Технология тихо делает свою работу, принося пользу. 💪 Так почему с AI должно быть иначе? Возможно, стоит сместить фокус с самой технологии на качество взаимодействия с пользователем. Если система может тихонько решить задачу, улучшить опыт и не кричать об этом с каждого экрана — это ли не наша цель? Конечно, специалисты по праву могут возразить: пользователи должны знать, когда их данные обрабатывает AI на своих секретных серверах. Но давайте будем честны: любые облачные сервисы уже давно обрабатывают наши данные на "сторонних серверах", кроме староверов с серверами в кладовках. С точки зрения пользователя, фундаментальной разницы нет. Единственное критически важное исключение — ситуации, где AI может ошибаться или «галлюцинировать». В таких случаях предупреждение необходимо, чтобы пользователь проверял информацию. Но во всех остальных — зачем разрушать магию? ✨ В ментальной модели человека ему совершенно не важно, какая технология работает «под капотом».

Я считаю, что для развития очень важно сохранять любознательность и интерес к окружающему миру, пытаясь понять, почему одни вещи работают, а другие — нет. ❓Почему реклама в метро кажется такой уродской? ❓Зачем все покупают новые айфоны, хоть объективной ценности в них мало? ❓Как из чёрной жижи получают бензин? ❓Насколько прибыльно продавать товары по себестоимости, как это делает Costco? В общем, важно, чтобы вас что-то по-настоящему интересовало и заставляло искать ответы. И вот недавно я наткнулся на один интересный проект. В нём нет ничего сложного, но мне очень понравилась подача идеи непостоянства времени. Я решил поэкспериментировать и повторить этот эффект, сделав что-то похожее, только наоборот. Получилось, возможно, не так круто, как в оригинале, зато в результате у меня остался компонент шейдера, который умеет делать эффект с несколькими настраиваемыми слоями. Охотно делюсь им и с вами. А что вы в последнее время делали просто потому, что было интересно?

Давайте немного поговорим про Competitors evaluation. В последнее время просматриваю много портфолио, где звучит подобное словосочетание. Однако дизайнеры под ним подразумевают разные вещи. 1️⃣Чаще всего под анализом конкурентов имеется в виду простой feature comparison. Это когда дизайнер сделал табличку с разным функционалом и отметил крестиками и галочками, что у кого есть. Пользы от такого упражнения не так много — вы не можете сказать, какая из фич будет полезной и почему она вообще имплементирована, а просто отвечаете на вопрос «что» есть у конкурентов. 2️⃣Следующим шагом будет более продвинутый подход, где мы переходим от «что» к «как». Тут дизайнеры уже обращают больше внимания не на наличие фичей, а на сам flow их работы. И здесь, конечно, нам помогают такие любимые сервисы, как Mobbin, где всё будто лежит по полочкам и мы можем поискать нужные кусочки взаимодействия и компоненты. И если у вас есть подписка, то такой ресёрч представляет собой прогулку по летнему саду. А если подписки нет… доступ к всего паре скринов с онбординга, а дальше протянутая рука за 15 баксами в месяц. Я чисто ради интереса решил поискать аналоги, и вот что получилось: 🧠 Mobbin — любимая классика, но для большинства проектов можно посмотреть всего 2 скрина, а дальше только за 15 баксов. Хотя вот добавили веб-сайты к мобильным приложениям, а также можно глянуть сами flow с микровзаимодействиями. 🧠 Appshots — достойный аналог. Всё то-о-очно так же. Аппов, правда, поменьше. А денег просят больше. 🧠 Screen Book — если вам интересны не только зарубежные аппы, но ещё хотите узнать, что происходит прямо рядом с вами, чтобы учесть локальные особенности, — очень рекомендую. Коллекция пока не такая большая, ограниченная аппами, но вся основная функциональность, как в Mobbin. Можно искать и скрины, и компоненты; flow пока, к сожалению, нет. Вместо них полные наборы скринов и анимации. Да и цена, как бы, 10 баксов за полгода. 🧠 Banani — есть пара десятков бесплатных аппок для ревью. Но тут фишка в другом. Все скрины используются как топливо для AI, чтобы сгенерить для вас уникальный реф. Для сравнительного анализа вообще не подходит, но поиграться с flow интересно. Лично моё отношение к такого рода коллекциям — смешанное. Да, с одной стороны, это очень тяжёлый труд — собрать по крупицам все стейты аппов, запаковать их во flows, наделать микроанимаций. Это титанический труд, который точно должен быть оплачен… если он вам нужен. Если вы делаете что-то простое, думаю, гораздо проще взять ваших прямых конкурентов и попробовать их поиспользовать. Другое дело, если вы не хотите становиться клиентами банков и заводить тридцать карт. Тогда инвестиции в любой из приведённых выше аппов оправданы. 3️⃣ Но вернёмся к нашей основной теме. Ответ на вопрос «как» значительно повышает ценность анализа, ведь мы можем выбрать наиболее удобный вариант для конечного пользователя, но при этом всё ещё не понимаем потенциальную пользу каждого из flow или фич. И тут на сцену выходит вопрос «Зачем?». До этого уровня глубины докапываются не все, сколько бы я ни спрашивал на интервью. Как понять, какая фича полезная, а какая — просто «как у всех»? Для того чтобы это понять, нужно анализировать рынок, пользователей и бизнес, а не фичи. Я предлагаю в таких случаях строить Business Canvas (не Business Model Canvas, хотя и он сойдёт). Подробнее о них можно прочитать в книге «Стратегия голубого океана», но если кратко: нам нужно взять от пользователей значимые параметры выбора продукта, от рынка — потенциальную ценность по каждому из параметров, чтобы построить кривую ценностного предложения для каждого из конкурентов. А затем, глядя на весь Landscape, можно увидеть, где достаточно просто не лажать, а где есть реальная возможность выделиться. Конечно, эти детали больше подходят для определения позиционирования, чем для принятия дизайнерских решений, и при этом ценность этой информации для определения цели неоспорима. Так что делайте выводы и копайте глубже.

Сейчас рынок забит продуктами под завязку. Делать их стало проще простого: теорию знают все, инструменты доступны каждому. Но вот шанс сделать продукт коммерчески успешным всё ещё около 1% (а то и меньше). И дело не в том, что продукты плохие — наоборот, качество только растёт. Может, люди стали придирчивее? Не особо. Конкуренция? Есть такое. Но, кажется, это не главное. У меня есть версия поинтереснее. На днях попалась подборка приложений, которые стали популярными и заработали кучу денег без инвесторов и без полировки интерфейсов. Честно говоря, выглядят они… ну так себе. Так почему же глянцевые, отполированные до блеска продукты проигрывают каким-то кривеньким поделкам? Всё просто: ценность. Если у человека редкая задачка, он не горит желанием платить за решение (неожиданно, да?). Чаще он выбирает пострадать вручную, чем платить. И вот тут на сцену выходят бесплатные «уродцы», которые закрывают боль без лишних условий. Зачем платить, если можно не платить? А где искать эту самую ценность? Почти все эти «убогие» продукты начинались одинаково: автору что-то мешало жить, готовых решений не было (или были, но дорогие), и он на скорую руку собрал костыль для себя. А потом выложил — и понеслось. То есть всё началось с боли конкретного человека, а не с бизнес-плана. Повезло? Да. Но закономерность тут тоже есть. И вот мой вывод: деньги — это не цель, а следствие. Гораздо важнее поймать настоящую боль и снять её. Если у вас внутри зудит нерешённая проблема, но в кармане пусто — сделайте костыль для себя и поделитесь. Может, и другим зайдёт. А там, глядишь, и монетка зазвенит.

Если вы всё ещё не знаете, как можно впихнуть AI в ваш продукт, или девелоперы говорят, что это сложно или для богатых, то я советую ознакомиться с этим быстрым гайдом по MCP. После просмотра, эта абревиатура перестанет вызывать вопросы и станет понятнее, что такое этот Model Context Protocol, и чем он отличается от API. А значит вы сможете лучше понимать, что в вашем продукте вы сможете подвести под этот протокол (а что пока не нужно). Мы уже активно переписываем наши тулы для использования моделью, и это не сказать, что так уж сложно и дорого, хотя мне ж легко говорить, я же просто дизайнер. Но при этом скорость появления новых сценариев и функций поражает, ведь в большинстве случаев инфраструктура уже готова, и остаётся только рассказать модели, что есть и как с этим работать. В общем, удачи вам на этом поприще, и если у вас будут вопросы — не стейсняйтесь задавать :)

Затусили с Артёмом и затёрли за тяжёлую жизнь архитектора дизайн-систем. Нужны ли они ещё кому-то в 2025 году? Ещё и как, тут бы калекой не остаться, так с руками отрывают! И о том, какую роль играют «библиотекари» в жизни продукта тоже обкашляли. Не забыли и про то, куда расти, если по кайфу собирать и оптимизировать, а менеджером становится не хочется. В общем, выпуск получился живой и приятный. Приятного вам прослушивания (или просмотра). https://youtu.be/kCE6-wNrpUc

Сегодня был очень хороший день. Мало того, что мы Артёмом Черепановым так круто пообщались за дизайн-системных библиотекарей, так ещё и была встреча с командой одной небольшой компании Google, где они делились впечатлениями об успешно проведенном тестировании с использованием Display. Конечно, немодерируемое тестирование было только одной из частей исследования, но все равно приятно, что продукт, который ты делаешь на голом энтузиазме, помог такому гиганту проверить парочку своих гипотез. Вдохновляет. 🤣 Так что, если вы все ещё думаете, стоит ли заниматься какими-то сайд-проектом по кайфу... Сами решайте, короче 😪

😐 Omnipresent Impressor: пытаются сделать всё и сразу упуская из виду то, что важно больше всего. Они думают, что могут сделать всё быстрее и лучше команды и неохотно делятся работой с другими. Это создаёт вокруг них ореол вечной занятости, а значит и на развитие команды времени совершенно не остаётся. Из опыта скажу, что тут всё тоже лечится временем и доверием. Демонстрируйте результат, говорите о нём и со временем вам начнут больше доверять. Также неплохой стратегией будет часто запрашивать обратную связь о работе — так лидер будет вынужден смотреть на реальное положение дел, что вы реально делаете работу хорошо, чем просто продолжать думать, что вы ни на что не годны. 😋 Masked Manipulator: это те, кто говорят «вы отличная команда, но на выходных нужно поработать». В отличие от Solo solver они понимают ценность команды, но скрывают свои корыстные мотивы под слащавой маской дружелюбия. Как вы понимаете, такой манипулятивных подход негативно сказывается на команде, так как им приходится постоянно жить в страхе переработок и неожиданных пивотов. Работать с такими лидерами можно через однозначную постановку границ — сложно манипулировать тем, кто отстаивает своё личное пространство. Но ещё более действенным способом будет постановка целей для всей команды, такой, которую все поддержат — так и манипулировать не придётся. Справедливости ради стоит отметить, что это примеры деструктивного лидерства, и не все лидеры такие, хотя конечно, в каждом присутсвует кусочек того или друго архетипа. А ваш лидер похож на кого-то выше?

Интересные размышления про архетипы деструктивного лидерства. Авторы провели некий брейнсторм и вывели 6 основных поведенческих моделей деструктивного лидера, каждый из которых разрушает атмосферу по-своему. 😡 Directive Disruptor: лидер, который «знает, как правильно», который много кричит о том, что «мы станем новым Apple на рынке детской присыпки и сразу кидается в бой. Зачастую без детального погружения в предметную область он сразу бросается на амбразуру стараясь больше делать, чем думать. Держит возле себя только «проверенных» людей, которые делают, а тех, кто челенджит и заставляет тормозить отпихивает подальше. К сожалению, эффективно руководить в такой обстановке не получается, ведь та часть команды, которую затыкают не могут привнести свой вклад в развитие продукта и деморализуются, а те, кто херячат, как проклятые, быстро выгорают и… точно также деморализуются. В итоге мы получаем никакущую команду, и дай бог хоть какой-то результат. А если и исконное видение оказалось неверным — ещё и кучу потраченного времени и целый стол никому не нужной работы. Советы по работе с такими лидерами от авторов странные: беги, прячься, не отсвечивай… Но есть и дельные — попытаться понять его мотивы на человеческом уровне и донести ценность чужого мнения через мягкое сопротивление, без громких криков и байкотов. В каких-то случаях, после того, как вы заработаете доверие такого лидера, делая то, что он хочет, вы сможете выправить ситуацию. Но приготовьтесь, что это будет долго и не потеряйте себя по пути. 👐 Protective Parent: антипод тираничного деспота. Этот архетип наоборот слишком много сил тратит на то, чтобы ВСЕ в команде росли в тепличных условиях: оберегает их от стресса, берёт на себя всю негативную коммуникацию и критику. Да, поддержание хорошего климата в коллективе — это одна из самых главных задач лидера, однако если перегнуть палку то можно просто-напросто получить команду не способную нормально функционировать вне теплицы. Можно сказать, что это медвежья услуга. Если вы попали под влияние такого лидера, нужно найти в себе силы сказать «Ну маааам!», то есть однозначно выразить своё отношение к чрезмерной опеке. Скажите, что вы готовы к новой отвественности и можете самостоятельно брать ответственность за свои решения, а лучше докажите это делом предложив забрать часть работы лидера. 😎 Solo solver: достигаторы, которые оставляют команду позади. Не способны отстаивать решения и мнение команды, если там нет ничего для них. Делегируют создание культуры на команду, пока сами заняты «настоящей работой», за которую могут получить одобрение руководства. С такими ребятами работать трудно, так как в их системе ценностей нет такого понятия, как команда. Но если у вас получится донести бенефиты создания культуры взаимопомощи и продуктивности, они могут поменять своё мнение. Главное говорить на их языке visibility и business impact, о которых они смогут отчитаться. ☹️ Academic Purist: следуют только проверенным теориям управления и подходам к работе, описанным в книгах без учёта контекста. Scrum — только в чистом виде. Data-driven — только попробуй предложить что-то без доказательной базы. Подобная негибкость в подходах часто негативно сказывается и на продуктивности и на морали команды, так как никто не хочет делать безполезную работу. А педалирование идей, которые не находят отклика ни у стейкхолдеров, ни у команды — пустая трата ресурсов. Несмотря на то, что спорить с таким лидером, значит спорить с академически обоснованными книгами — очень трудно, это не значит, что не нужно пытаться. Попробуйте вывести такого лидера на парадокс и предложите использовать другие или адаптированные подходы чисто в рамках эксперимента. Такой подход может снять барьеры невосприимчивости и открыть глаза на более широкую картину.

У меня в закладочках уже давно живёт ресурс Failure Museum, как напоминание об ошибке выжившего. Мы часто видим истории успешного успеха, но вот о почивших начинаниях все почему-то говорят мало. А этот ресурс, как раз о них. Там собраны истории продуктов и компаний вышедших на рынок с гордо поднятой головой, под одобрительные аплодисменты, однако чей маршрут был построен не до галлереи славы, а на свалку истории. И чтобы такого не происходило, на самом деле много и не нужно, достаточно остерегаться 6 основных сил краха: 1. Product-Market fit 🎯, когда рынок уже перенасыщен или наоборот не готов к вашему гению, и люди просто не видят ценности в вашем продукте, а значит не будут его покупать. 2. Деньги 🪙, ну и не только, когда их не хватает, а когда деньги становятся главнее продукта и команд. Так размывается фокус и продукт обрекается на вечное скитание в тёмных водах. 3. Потребители.🤩 Не слушайте ваших конечных пользователей и точно пойдёте ко дну. Точка. 4. Конкуренция 👊 убивает. Если вы врываетесь на высоко конкурентный рынок как убийца чего-то... скорее сами падёте ещё не подобравшись к вашему заклятому врагу. Также, если не будете оберегать ваши подходы, технологии и команду — мозги растекутся а всё остальное будет скопировано и ваше конкурентное преимущество будет сведено на нет. 5. Время. 🕙 Окно возможностей может быть закрыто из-за дерьмовой внешней ситуации: медвежий рынок, тарифы, более перспективные направления. И если не подгадать время, можно и не начинать. 6. Команда. 🤣 Я убедился на собственном опыте. Если вся команда не готова вкладываться в проект (кто чем может), то всё быстро забуксует и вы потеряете инерцию. Продукт-то может и будет выпущен, но вот дальше... Пф-пф-пф... И остановится на обочине, как машина без топлива. Всё это может показаться прописной истиной, но блин, с основ всё и начинается. Что стоит чекнуть этот список перед стартом новой инициативы и честно ответить на вопрос: «А всё у нас есть?» И если нет — сэкономить время и деньги. Желаю, чтобы ваши проекты запускались гладко, как выбритое колено.